PVLAN Example – 3560 – 12.2(46)


vtp mode transparent
vlan 111
private-vlan primary
private-vlan association 222,333
vlan 222
private-vlan community
vlan 333
private-vlan isolated
interface FastEthernet0/1
Description * * PVLAN-COMMUNITY * *
switchport private-vlan host-association 111 222
switchport mode private-vlan host
interface FastEthernet0/2
Description * * PVLAN-COMMUNITY * *
switchport private-vlan host-association 111 222
switchport mode private-vlan host
interface FastEthernet0/3
Description * * ISOLATED * *
switchport private-vlan host-association 111 333
switchport mode private-vlan host
interface FastEthernet0/4
Description * * PVLAN-PROMISCUOUS * *
switchport private-vlan mapping 111 222,333
switchport mode private-vlan promiscuous

# show vlan private-vlan

Primary Secondary Type Ports
——- ——— —————– ——————————————
111 222 community Fa0/1, Fa0/2, Fa0/3, Fa0/8
111 333 isolated Fa0/4, Fa0/8

#show vlan private-vlan type

Vlan Type
—- —————–
111 primary
222 community
333 isolated


Cisco ASA LDAP attribute-map the things they did’nt write clearly


The Cisco ASA introduced a feature to allow a granular control of VPN access (under one form or another) based on LDAP group membership. This post is after working through a number of configurations that just did not work or worked in a sporadic manner. This configuration is based on AnyConnect Essentials SSL/IPSEC VPN authentication and access. I learnt that just because it does not work could infer two possibilities:

1) Its configured wrong

2) Its a Bug (this caused me 4 hours of head scratching on 8.4(5)) 

The configured LDAP attribute map is as follows:

ldap attribute-map LDAP-ATTRIB-MAP
  map-name  memberOf Group-Policy
  map-value memberOf CN=VPN_Admins,OU=VPNADMIN,OU=OX14_Users,DC=OX14,DC=LOCAL GPO-ALLOW
  map-name  primaryGroupID Group-Policy
  map-value primaryGroupID 513 GPO-NOACCESS

The configuration identifying this LDAP value “memberOf CN=VPN_Admins,OU=VPNADMIN,OU=OX14_Users,DC=OX14,DC=LOCAL” maps to a VPN Group Policy on the ASA of GPO-ALLOW. In a means to deny any other users from connecting is matched with “primaryGroupID 513” (Domain Users) maps to a VPN Group Policy on the ASA of GPO-NOACCESS. The LDAP attribute map is then assigned to a AAA LDAP server group.

Your friend in this is the debug console and specifically “debug LDAP 255”.  When looking at the output of the debug you can see the LDAP groups being matched to the ASA Group Policies. 

memberOf: value = CN=VPN_Admins,OU=VPNADMIN,OU=OX14_Users,DC=OX14,DC=LOCAL
mapped to Group-Policy: value = GPO-ALLOW
mapped to LDAP-Class: value = GPO-ALLOW

memberOf: value = CN=VPN_Users,OU=VPNUSER,OU=OX14_Users,DC=OX14,DC=LOCAL
mapped to Group-Policy: value = GPO-NOACCESS
mapped to LDAP-Class: value = GPO-NOACCESS



I’ll update this soon with  a full point and click ASDM guide.

Wireless Aerial Coverage


The following link was one I found when investigating the use of 1131AG access points. The positioning on a ceiling is certainly better qualified after reviewing this document.




Update the 000-default file with the following details below to add basic authentication.

<VirtualHost *:80>

ServerAdmin webmaster@localhost

DocumentRoot /var/www

<Directory />

Options FollowSymLinks

AllowOverride None

order deny,allow


<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews

AllowOverride none

order allow,deny

allow from all


ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

        <Directory “/usr/lib/cgi-bin”>

                AuthType Basic

                AuthName “CVS REPO”

                AuthUserFile /etc/apache2/.htpasswd

                AllowOverride All

                Require valid-user


The command below will allow you to create a new user and it will lead you through adding a password for that user.

network@S-ABD-RANCID:$ sudo htpasswd -c .htpasswd myuser

Cisco ASA, IPSEC bypass options (bozo)


To permit ANY packets that come from an IPsec tunnel without checking any ACLs such as the OUTIDE_ACCESS_IN The following example enables IPsec traffic through the ASA without checking ACLs:

hostname(config)# sysopt connection permit-vpn

VTP (never use it) you need to know it


VLAN TRUNKING PROTOCOL is designed to ease administration  of a large number of switches. It manages addistions, deletions and renaming. You can only apply one VTP domain to a switch.

There are 3 versions of VTP and only two of those are actively used (V3 is CAT/OS). VTP is a method of synchronising the vlan databases of switches. The term domain is used to identify a cluster/group of switches. If the databases are to be shared then the domain name and any passwords set must match (not totally true, read below for more details).

VTP advertisements are based upon the revision number and are sent when a change is made or every 5 minutes. The advertisments are multicast frames.

A summary advertisment is sent out every 300 seconds and if a change occurs.

A subset advertisment after a configuration change. VLAN name, SAID value, type and MTU.

A request from client switch used to obtain up to date information.

Each change made to a vlan will increase the revision number. A switch will compare revision numbers when it receives an advertisement. A switch will overwrite its VTP database if the update from one of it’s peers is higher (potentially making an automatic change to the assigned vlan’s). The advertisement is forwarded onto any neighbours. If the switch receives a VTP advertisement with a lower revision it will reply with it’s advertisement to update it’s neighbour.

The roles are:

SERVER: This is the default and will allow the switch to create, delete and rename vlan’s.

CLIENT: Apparently clients cannot make changes. However, I have seen events where client switches have been able to pass on updates to server peers.

TRANSPARENT: Allows the creation, deletion and renaming vlan’s but all information remains local. This mode will forward VTP information to its peers.

The use of show vtp status identifies the version in use, the revision number and the number of vlans that are being passed around via VTP.

Q-in-Q VLAN tunnels


Q-in-Q allows already tagged frames across a network by tunnelling them inside a single vlan. The process adds a second 802.1Q tag to each frame. As the packets traverse the network the network the infrastructure see’s the outside tag and forwards based on that vlan. Q-in-Q tunnels are usually implemented by service providers to encapsulate a customers multiple vlans into a single vlan.

Eg: as a simple example

Customer vlans 1,2,3,4,5
Service provider vlan 100

Customer switch trunk vlans 1-5 —-> (service provider dot1q-tunnel vlan 100) ——> vlans 1-5

This is enabled with:

switchport mode dot1q-tunnel

The tunnel interfaces should be setup at either end of the overall link.