Private VLANs - How they really work

You're probably already familiar with the basics of a private VLAN: it allows you to group hosts in a single subnet on Ethernet, but limit which hosts can talk to each other at layer 2.  A common design is to have the default gateway accessible to the entire subnet, but prevent the individual hosts from talking to each other (an isolated VLAN). Another common design is to break the VLAN up into various smaller groups that can talk to each other (community VLANs), but allow all hosts in all groups to talk to the default gateway. Instead of a default gateway, the promiscuous host might be a community server, such as a backup server.

Configuring them is not very tricky.  Our topology will consist of two 3560 switches, SW1 and SW2, trunked together on Fa0/13.  R1 will simulate our default gateway, on 192.168.0.1.

SW1:

vlan 124

  private-vlan primary

  private-vlan association 216,402

vlan 216

  private-vlan community

vlan 402

  private-vlan isolated

interface FastEthernet0/1

 switchport private-vlan mapping 124 216,402

 switchport mode private-vlan promiscuous

interface FastEthernet0/13  ! Trunk to SW2

 switchport trunk encapsulation dot1q

 switchport mode trunk

SW2:

vlan 124

  private-vlan primary

  private-vlan association 216,402

vlan 216

  private-vlan community

vlan 402

  private-vlan isolated

interface FastEthernet0/13 ! trunk to SW1

 switchport trunk encapsulation dot1q

 switchport mode trunk

interface FastEthernet0/2  ! Connects to R2, a community host

 switchport private-vlan host-association 124 216

 switchport mode private-vlan host

interface FastEthernet0/4 ! Connects to R4, a community host

 switchport private-vlan host-association 124 216

 switchport mode private-vlan host

interface FastEthernet0/6 ! Connects to R6, an isolated host

 switchport private-vlan host-association 124 402, an isolated host

 switchport mode private-vlan host

I'm not going to go over this config in extreme detail, because this information can be found very easily anywhere.  I just needed a baseline to show a few other interesting things.

R1 is the promiscuous default gateway, R6 is an isolated host, R2 and R4 are in a community VLAN.

First, let's make sure it works.

Can everyone reach R1?

R2#ping 192.168.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R4#ping 192.168.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R6#ping 192.168.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

OK, our promiscuous port works.

Can R2 ping R4?

R2#ping 192.168.0.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Looks good, community VLAN works.

Can R6 reach anything besides R1?

R6#ping 192.168.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R6#ping 192.168.0.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Nope, it really is isolated.

So it works - fantastic.  But how does it work? Answering that question takes a bit of research.

This page documents the high-level workings:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/pvlans.html

Specifically,

"• Primary VLAN— The primary VLAN carries unidirectional traffic downstream from the promiscuous ports to the (isolated and community) host ports and to other promiscuous ports.

• Isolated VLAN — [edited for brevity] An isolated VLAN is a secondary VLAN that carries unidirectional traffic upstream from the hosts toward the promiscuous ports and the gateway.

• Community VLAN—A community VLAN is a secondary VLAN that carries upstream traffic from the community ports to the promiscuous port gateways and to other host ports in the same community. [edited for brevity] "

So, in a nutshell, the primary VLAN carries traffic from the promiscuous port to everyone else, unidirectionally.  An isolated VLAN carries traffic from every isolated host to the promiscuous port. And a community VLAN carries bidirectional traffic for members of the community, but only unidirectional traffic towards the promiscuous port.

OK, we got that, but still, how does it work?

It's all a clever manipulation of MAC address learning.

Referencing the pings I made above, let's look at the mac table on SW1 and SW2.

SW1#show mac address-table | i 124|216|402

 402    0013.c460.2be0    DYNAMIC pv  Fa0/1

 402    0019.2fb8.d552    BLOCKED     Fa0/13

 124    0013.c460.2be0    DYNAMIC     Fa0/1

 124    0019.2fb8.d552    DYNAMIC pv  Fa0/13

 124    0019.e880.09c0    DYNAMIC pv  Fa0/13

 216    0013.c460.2be0    DYNAMIC pv  Fa0/1

 216    0019.e880.09c0    DYNAMIC     Fa0/13

SW2#show mac address-table | i 124|216|402

 402    0013.c460.2be0    DYNAMIC pv  Fa0/13

 402    0014.1ceb.f60f    BLOCKED     Fa0/13

 402    0019.2fb8.d552    BLOCKED     Fa0/6

 124    0013.c460.2be0    DYNAMIC     Fa0/13

 124    0014.1ceb.f60f    DYNAMIC pv  Fa0/13

 124    0019.2fb8.d552    DYNAMIC pv  Fa0/6

 124    0019.e880.09c0    DYNAMIC pv  Fa0/2

 124    0024.c4eb.ed68    DYNAMIC pv  Fa0/4

 216    0013.c460.2be0    DYNAMIC pv  Fa0/13

 216    0019.e880.09c0    DYNAMIC     Fa0/2

 216    0024.c4eb.ed68    DYNAMIC     Fa0/4

There's a lot going on there, so let's break this down into more manageable chunks.

R6 is our simplest host - it's a single isolated host, so let's start there.

R6#show int fa0/0 | i bia

  Hardware is Gt96k FE, address is 0019.2fb8.d552 (bia 0019.2fb8.d552)

So we now know that 0019.2fb8.d552 is R6's MAC address on it's Fa0/0 port.

SW1#show mac address-table | i 0019.2fb8.d552

 402    0019.2fb8.d552    BLOCKED     Fa0/13

 124    0019.2fb8.d552    DYNAMIC pv  Fa0/13

SW2#show mac address-table | i 0019.2fb8.d552

 402    0019.2fb8.d552    BLOCKED     Fa0/6

 124    0019.2fb8.d552    DYNAMIC pv  Fa0/6

We see some new terms here in the CAM table, "BLOCKED" and "DYNAMIC pv".

Best I can tell without any documentation on these, this is what they mean:

BLOCKED = Do not forward traffic to this MAC (essentially the same as not learning it)

DYNAMIC pv = This is a receive-only MAC.

So putting that in context of R6, R6 is allowed to SEND on 402, and can RECEIVE on 124. It cannot receive on 402, because the MAC is "BLOCKED".  This is what enforces an isolated VLAN.  The MAC learning process takes place, but the CAM table flags them as unusable.  Therefore, any traffic sent towards that MAC on that VLAN would be discarded.

Let's look at our earlier definition of isolated VLAN from Cisco:

• Isolated VLAN — [edited for brevity] An isolated VLAN is a secondary VLAN that carries unidirectional traffic upstream from the hosts toward the promiscuous ports and the gateway.

This is true, based upon that R6 (and any other future isolated host) can't learn MACs on that VLAN, except...

R1#show int fa0/0 | i bia

  Hardware is AmdFE, address is 0013.c460.2be0 (bia 0013.c460.2be0)

SW1#show mac address-table | i 0013.c460.2be0

 402    0013.c460.2be0    DYNAMIC pv  Fa0/1

[edited for brevity]

R1's MAC can be learned on 402.  So R6 will be able to send frames out 402 towards R1.  This completes the concept that 402 is a "one way" VLAN from Isolated -> Promiscuous.

But what about R1 -> R6?

• Primary VLAN— The primary VLAN carries unidirectional traffic downstream from the promiscuous ports to the (isolated and community) host ports and to other promiscuous ports.

SW1#show mac address-table | i 124

 124    0013.c460.2be0    DYNAMIC     Fa0/1

 124    0019.2fb8.d552    DYNAMIC pv  Fa0/13

on Fa0/1, we see R1, and on Fa0/13, we see R6.  R6 has the "DYNAMIC pv" status, meaning it is a receive-only MAC.  Frames originating from 0019.2fb8.d552 would not be accepted, only frames towards 0019.2fb8.d552.  We'll be generating more traffic in a moment, and the switches will learn more on vlan 124.

Now let's look at the community hosts.

First, re-generating traffic for MAC learning:

R2#ping 192.168.0.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R2#show int fa0/0 | i bia

  Hardware is AmdFE, address is 0019.e880.09c0 (bia 0019.e880.09c0)

R4#show int fa0/0 | i bia

  Hardware is Gt96k FE, address is 0024.c4eb.ed68 (bia 0024.c4eb.ed68)

There's our MACs for R2 and R4.

How's the table look?

SW1#show mac address-table | i 0019.e880.09c0 ! R2

 124    0019.e880.09c0    DYNAMIC pv  Fa0/13

 216    0019.e880.09c0    DYNAMIC     Fa0/13

SW1#show mac address-table | i 0024.c4eb.ed68 ! R4

 124    0024.c4eb.ed68    DYNAMIC pv  Fa0/13

 216    0024.c4eb.ed68    DYNAMIC     Fa0/13

SW1#show mac address-table | i 0013.c460.2be0 ! R1

 402    0013.c460.2be0    DYNAMIC pv  Fa0/1

 124    0013.c460.2be0    DYNAMIC     Fa0/1

 216    0013.c460.2be0    DYNAMIC pv  Fa0/1

You should notice immediately we don't have any "BLOCKED" status here.  That's because R2 and R4 can talk to each other. This port has no affiliation with the isolated VLAN in any fashion, so R2 and R4's MACs simply aren't learned on VLAN 402. We do have some "DYNAMIC pv".  The primary VLAN is still used to carry traffic from R1 (promiscuous) to R2 and R4.  Therefore, R2 and R4 must be learned on VLAN 124 (as "DYNAMIC pv"), but not able to speak, or they'd be able to reach hosts outside their community.  Also, R1 should be "DYNAMIC pv" on 216 (community VLAN), so that replies are forced over 124 (primary VLAN).

With that wrapped up, here's some other cool stuff I did while working on this!

- Pushing private VLANs through a switch that doesn't support them.  This is a bad, bad idea.  Before I labbed this out this granuarly, I thought, sure, why not?  If the switch doesn't know it's a private VLAN, the whole "DYNAMIC pv" and "BLOCKED" MAC learning concepts stop working, and all hell breaks loose.  Just don't do it!

- Try putting a regular, non-private, access port up on one of the primary or secondary VLANs.  It just doesn't work - you can send frames at the port and the switch just won't learn your MAC and ignores all the traffic.

- Not so exotic on my last bullet, but what about using an SVI as part of a private VLAN?  Well for starters, this is totally doable, but only as a promiscuous port. You'd be using the switch as a default gateway instead of a standalone router.  The config looks like this:

interface Vlan124

 ip address 192.168.0.249 255.255.255.0

 private-vlan mapping 216,402

R6#ping 192.168.0.249

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.249, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Trying to make an SVI with vlan 216 or 402 does not work.

Another oddity:

SW1#show int vlan124 | i bia

  Hardware is EtherSVI, address is 0014.1ceb.f641 (bia 0014.1ceb.f641)

SW1#sh mac address-table | i 0014.1ceb.f641

SW1#

Well that's not something you see every day...

Happy Studying,

Jeff