May 9

Private VLANs

Posted by Marius Bunget

PVLANs provide layer 2 isolation between ports within the same broadcast domain. There are three types of PVLAN ports:

  • Promiscuous— A promiscuous port can communicate with all interfaces, including the isolated and community ports within a PVLAN.
  • Isolated— An isolated port has complete Layer 2 separation from the other ports within the same PVLAN, but not from the promiscuous ports. PVLANs block all traffic to isolated ports except traffic from promiscuous ports. Traffic from an isolated port is forwarded only to promiscuous ports.
  • Community— Community ports communicate among themselves and with promiscuous ports. These interfaces are separated at Layer 2 from all other interfaces in other communities or isolated ports within their PVLAN.

IP Addressing
All the members of the Private VLAN can share a common IP Space where the IP space is assigned to the Primary VLAN. The hosts connected to isolated or community ports can have the addresses assigned from the address space of the Primary VLAN.


Steps to Configure Private VLAN

1. Set VTP mode to transparent
2. Create Primary and Secondary VLANs
3. Map secondary VLANs to Primary VLANs
3. Configure ports in Secondary VLANs and assign VLAN memberships
4. Configure Promiscuous ports and map them to primary-secondary VLAN pairs


Switches S1 and S2  must be configured as follows:

Create vlans 101 and 102 and then associate them to the primary Vlan 100.

vlan 100
  private-vlan primary
  private-vlan association 101-102
vlan 101
  private-vlan community
vlan 102
  private-vlan community

On S1:

interface FastEthernet0/1
 switchport private-vlan mapping 100 101-102
 switchport mode private-vlan promiscuous
interface FastEthernet0/3
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
interface FastEthernet0/5
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

On S2:
interface GigabitEthernet0/4
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
interface GigabitEthernet0/6
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
interface GigabitEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
Mar 30

Securing a router or a switch involves not only filtering traffic with ACLs, but also means securing the device itself. Creating users with certain privilege levels is an important first step.  This can be done on a device by device basis or using a centralized authentication server. In any case, it involves using AAA (Authentication, Authorization and Accounting).

If using a centralized system for user authentication, the router or switch would be an authentication client. It will need to communicate with a server using a specialized protocol. Two such protocols are wide known: TACACS, a Cisco proprietary protocol and RADIUS, an open standard protocol. In a Cisco-centered  network, IOS authentication would work with Cisco’s ACS (Access Control Server), but in some cases , specially for lab purposes, ACS could be harder to get an setup.

A very quick way to setup an authentication server is to use FreeRADIUS, an open source server that uses the RADIUS protocol. It can be easily installed on a Linux box and used with minimum configurations. Here are the steps to setup:

Install the packet:

root@radiusserver# apt-get install freeradius

Add each client (router or switch) in the /etc/freeradius/clients.conf file. Each client is identified by its hostname and requires a password (secret).

root@radiusserver# vim /etc/freeradius/clients.conf

secret = authentications3cr3t
shortname = ClientRouter


Add each user that is allowed on the device.

root@radiusserver# vim /etc/freeradius/users.conf

iosuser Cleartext-Password := “icanhazroot”
DEFAULT Auth-Type := Reject

Start or restart the FreeRADIUS server:

root@radiusserver# /etc/init.d/freeradius restart

On the client side (the network device), AAA needs to be enabled, the RADIUS server configured and then the authentication need to be set to use an external server.

ClientRouter(config)# aaa new-model
ClientRouter(config)# radius-server host $RADIUS_SERVER_IP auth 1812 acct 1813 key authentications3cr3t
ClientRouter(config)# aaa authentication login default group radius

This is a basic configuration of a FreeRADIUS server, but it can also provide features like LDAP intergration.

Aug 3




The Host in the network should get its IP address from a DHCP server.

Relay is the default router for the Host, but doesn’t have a DHCP service running. It will pass any DHCP requests from it’ f1/0 interface to the DHCP server that has DHCP pools configured on it, using the “ip helper-addres” command.

Between the DHCP router and the Relay router there is a public network, but behind Relay, there is a private network (Host is part of that network).  Relay will use NAT with overload (PAT) to service the private network.

Relay uses DHCP as it’s default route to the Internet, but DHCP doesn’t know about the private network in which Host is in (private networks shoudn’t be permitted to be accessed from the Internet).



ip dhcp pool DHCP_POOL

interface FastEthernet0/0
ip address


interface FastEthernet0/0
ip address
ip nat outside

interface FastEthernet1/0
ip address
ip helper-address
ip nat inside

ip nat inside source list NAT_HOSTS interface FastEthernet0/0 overload

ip access-list standard NAT_HOSTS


interface FastEthernet1/0
ip address dhcp


Relay will receive a DHCP request (broadcast) on F1/0 interface. Because of the “ip helper-address“, Relay will transform the request from broadcast to unicast and send it to the DHCP router. The  DHCP request will reach the router, it will assign  an IP from the pool, but the reply will never reach Host.


Using “debug ip dhcp server events“, “debug ip dhcp server packet” and “debug ip packet“, we can find out the problem.

The first thing that could come to mind is the fapt that if Relay receives a packet on F1/0 interface ( it will send an unicast message with the source IP address of that interface and a destination address of the ip-helper server. This is not true. The relayed request is considered to be generated by the local router (Relay). This means that the source IP address of the relayed request is that of the outgoing interface to the DHCP Server. Here is the debug ip packet output:

*Mar  1 02:33:23.127: IP: tableid=0, s= (FastEthernet0/0), d=200.0.0. 1 (FastEthernet0/0), routed via RIB

If  the source address of the IP packet does not have an IP address from the network, how does the DHCP Server know from witch pool to give out a free address. The answer is a field in the DHCP protocol, called GIADDR (Gateway IP Address). The value of this field will be the IP address of the interface in the private network.

The problem is that after the DHCP server chooses an IP from the pool, it will reply to the unicast request, with another unicast packet that has the destination IP the GIADDR, not the source address of the request. The output from debug ip dhcp server events:

*Mar  1 03:13:33.719: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d 63.6330.322e.3035.6230.2e30.3031.302d.4661.312f.30 through relay
*Mar  1 03:13:33.731: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d63.6330.322e.3035.6230.2e30.3031.302d.4661.312f.30 (
*Mar  1 03:13:33.731: DHCPD: unicasting BOOTREPLY for client cc02.05b0.0010 to relay

The DHCP router doesn’t know about the network because that is a private network behind a NAT.

A solution to the situation is to add a static route on the DHCP router to the private network. But this would ruin the purpose of NAT. A better solution is to avoid the scenario by design (still, the situation could come up in lab environments and you should now know why it behaves the way it does)

Nov 8

To lower broadcast traffic in our network or for some extra security we use Virtual LANs. Cisco switches can be configured with Ethernet VLAN IDs ranging from 1 to 1001 and, with the extended VLANs, from 1006 to 4096. For trunking, we can use the IEEE 802.1Q (dot1q) protocol that can support the extended VLANs (1-4096).

The fisrt important rule of implementing VLANs in a network tells us that a switch won’t forward a frame from a VLAN if it does not know about that VLAN. All the switches in a network need to know about all the VLANs regardless of the fact that they have or not local access ports in those VLANs. So, we need to go to every switch and configure all the VLAN IDs, or we could use VTP (VLAN Trunking Protocol), Cisco’s proprietary protocol that automatically configures network-wide all the VLANs. Remember, VTP is on by default, in Server mode.

But the use of VTP can sometimes lead to unexpected behavior on the switch. Most common is when you try to reset your switch and you delete the running-config and the flash:vlan.dat, reload the IOS and find all your VLANs still there. If you have VTP configured in your network (without authentication), upon boot-up, the switch will get the VLAN information from it’s VTP neighbors, the reason being that the default configuration is Server mode. The solution would be to set the switch in Transparent mode and delete the VLANs.

The configuration of VTP Transparent mode causes another strange exception. As we are have studied in CCNA, the vlan.dat file in flash holds the VLAN information for a switch, not the running-config in NVRAM. This is not true when dealing with Transparent mode. If the switch is in VTP transparent mode, the VLAN information IS stored in running-config. So, if you configure vtp mode transparent, configure some VLANs, delete the vlan.dat and reboot, you will find the VLANs still there.

One more situation where VLANs are stored in running-config is when we use extended VLANs. Regardless of VTP mode, if we configure a VLAN with an ID greater than 1006, it will be stored as an entry in running-config. Extended VLANs will NOT be carried through VTP, so it makes sense not to store them in vlan.dat, because the switch will try to synchronize the file with the VTP information.

Nov 4

Networking is sometimes hard not because of the concepts that you need to apply, but because of the difference in implementation of some protocols on the equipment. For example, the default settings for DTP differ from one switch model to the next.

DTP (Dynamic Trunking Protocol) is used to negotiate a trunk link between two switches. From the DTP point of view, a port can be ‘desirable‘ (it will actively try to negotiate a  trunk), ‘auto‘ (it will form a trunk if the other side wants to be a trunk) and ‘non-negotiate‘ (port will not negotiate the link). The reason for this protocol is to have a working access or trunk link immediately after you connect the switch to the network.   Most of the combinations are:

  • auto – auto => access
  • auto – desirable => trunk
  • desirable-desirable => trunk
  • auto – trunk => trunk
  • auto – access => access
  • desirable – trunk => trunk
  • desirable – access => access

What you should pay attention to is the default setting of a port on different switch models. On a 2950 (Layer 2 switch) and a 3550 (Layer 3 switch), a port is, before any configurations, in desirable. If you connect two of these switches, you will have a trunk link formed. On the other hand, on a 2960 or a 3560, a port is in auto, so between these models, you will have an access port (by default, in VLAN 1). Even more problems could arrive when you have in a network switches of different models. If you connect a 2960 and a 2950, because the first is in auto and the second  is in desirable, a trunk link will be negotiated, so you should be careful when dealing with these kinds of situations.