Wednesday, November 30, 2016

Introduction to Private VLANs

 on  with No comments 
In , ,  
Private VLANs are a technique used to restrict communication between hosts or group of hosts within a VLAN.  In other words, isolation of hosts and/or groups of hosts. These differ from Private VLAN Edge, which I have previously blogged about.  Private VLAN Edge is a much simpler topic, in theory and in practice, that is the only option on lower end switches such as the Catalyst 2950.   Private VLANs are more featureful, and by extension of that, a bit more complex to implement.

The need for Private VLANs can be imagined when thinking about the early days of cable modems and DSL.  Poorly configured ISPs allowed broadband customers to see one another on the Internet.  At the time, many customers did not have a router at home, they would just connect their PC directly to the cable modem.  In the interest of IP address conservation, ISPs would put entire neighborhoods (or even more) on to a single subnet and on a single VLAN, and this allowed directly connected PCs to see one another.  Network Neighborhood in Windows 98 found many of my neighbors back when I first signed up for Media One broadband.

In the ISP situation, what would their options be?  Subnet their address range down and give each customer a /30?  That would essentially lose 75% of their address space as a /30 would assign 4 IP addresses to each customer instead of 1.  Also note that they'd need a VLAN per customer, and switches are limited in the number of active VLANs that they support.  So they would need to limit the number of customers per switch, which would increase the number of switches necessary, as well as routers to connect those switches.  They could use VLAN ACLs or other advanced techniques, but that could get very complex very quickly, and may not scale well.

Also consider a co-location facility hosting web servers for a number different clients.  They want those servers to be reachable from the Internet, but most likely not reachable from each other.  This is especially true if one were to become infected with a fast spreading worm.  A client at the co-location facility may also have more than one server.  These servers may need to communicate to one another, and to the Internet, but not to other clients.  How does the colo handle this increasingly complex setup?  One possible solution is Private VLANs which allows granular separation of customers.

In the Private VLAN, there are two types of port assignments.  First is the Host port, which inherits its behavior from the Secondary VLAN type it is assigned to.  This is just your standard host.  A server, workstation, printer, etc.   Next is the Promiscuous port.  This port is able to communicate with any other port in the Private VLAN, even those in an isolated secondary VLAN.  Promiscuous ports are generally where you would have a router or a firewall rather than a workstation or server.

To use Private VLANs, you start with an overall container, which is known as the Primary VLAN.  Think of the Primary VLAN as you would the standard VLANs you know, but with additional features.  The Primary VLAN works pretty much like any other VLAN on the switch for the most part, with few caveats that I'll get to as they come up.

Inside of this Primary VLAN will be one or more Secondary VLANs.  There are two primary types of Secondary VLANs.  First is the Isolated VLAN.  This type of Secondary VLAN contains individual hosts that cannot communicate with each other or other secondary VLANs, but can communicate with promiscuous ports.  Second is the Community VLAN.  This type of Secondary VLAN contains hosts that can communicate with each other but not with hosts in other Secondary VLANs.  In Cisco-speak, the Primary VLAN forwards downstream from promiscuous ports to community and isolated ports.  The important takeaway is that Secondary VLANs can never communicate with other Secondary VLANs but can always communicate with promiscuous ports. Also note that these rules apply to all traffic: unicast, multicast and broadcast.  So keep this in mind if you need to use DHCP with an isolated secondary VLAN for example.

Private VLAN's can be trunked and span multiple switches as well. In this case, the secondary VLAN will be used to tag the frames as they travel the trunk.   Because of this, you may have to configure the Private VLAN settings manually on each switch. In Cisco switches, VTP3 has TLVs to carry Private VLAN information, but not all switches support VTP3. And VTP in any version is proprietary to Cisco, it's not supported in other manufacturers equipment.

In Cisco switches, they are supported on the Catalyst 3560 and higher, which includes the 3750, 4500 series and 6500 series switches, as well as other advanced platforms.  An interesting switch in this regard is the 3550.  With the right IOS, the commands for PVLANs are there, and you can enter them.  But there is some disagreement on exactly how far this gets you.  Cisco states for the record that PVLANs are not supported on the 3550, which many have taken to mean that you are free to use them, however Cisco will not provide you any technical support in that regard (or at least wouldn't when the 3550 was still a supported platform).  I've also seen it written in places (including a blog post by Wendell Odom if memory serves me correct) stating that while it will take the commands, and that they'll show up in the configuration, there will be no effect on the operation of the switch.  In other words, they are merely cosmetic.  As I have a 3550 switch in the lab and an assortment of IOS images to test out, I plan to visit this topic in the near future.  PVLANs are also supported by IOU L2 images should you not have access to real hardware.

Though Private VLANs are originally a Cisco developed concept, they are described in RFC 5517, Cisco Systems' Private VLANs.  It's supported by Arista, Brocade, Juniper, Netgear, and others.  They're also supported in virtual switches in Hyper-V (somewhat) and VMware.

If you don't have access to a Cisco switch or IOU L2 images to use, Arista vEOS images support PVLANs in a very Cisco-like manner.  In fact, most commands on Arista's vEOS virtual switch platform are very Cisco-like.  A friend of the CCNA group, Stuart Fordham has previously blogged about his experience with using Arista switches during his CCIE Security studies in a few posts.  At this point, IOU is available and it works well for most tasks, but Arista is an option at this point.  Arista vEOS can be found here.  It was downloadable with a free account the last time I checked, but that was a while back and YMMV.

In this post, I went over the basics of Private VLANs.  In future posts, I'll talk about configuring Private VLANs as well as investigating the commands on 3550 switches further.
Share:

0 comments:

Post a Comment

Discuss this post!