What is a LAN Switch?
Logically, we really need to start with the question, what is a LAN switch?
A LAN switch is a OSI model Layer 2 device, logically similar to a bridge. We’ll primarily focus on Ethernet (Fast Ethernet, Gigabit Ethernet) switches but much of what we say also applies to Token Ring and FDDI.
As you know, bridges learn where computers are by observing source MAC addresses in LAN frames as they pass through the bridge. After first powering on, a bridge forwards frames on all ports and is pretty much indistinguishable from a hub/repeater (except that it regenerates frames, so it does not count towards the Ethernet cable length limitation or hub/repeater 5-4-3 rule). As the bridge learns which MAC address was sourced on which port, it can then be selective about what port(s) a frame is forwarded to, only forwarding the frame to the port appropriate for the destination MAC address.
There are still some frames a bridge has to forward to all ports, flooding it throughout a network of bridges (and switches). They (in principle) include broadcasts, multicasts, and MAC layer unicasts to an unknown destination MAC address.
Loops are bad in bridged networks, because flooded frames can circulate endlessly, consuming all bandwidth. Bridges use a protocol to defeat looping paths, called Spanning Tree Protocol (STP). We may go into STP in a later article. (Kennedy says the above-mentioned book has 200 pages of Good Stuff on STP, and he actually has more to say about it — a scary thought. But if you need a quick fix of STP, you can buy the book!)
So what is it that makes a LAN switch different than a bridge? Well, for me bridges were kind of dumb and slow. Switches have enough backplane (or chip fabric, or whatever) to be non-blocking. This means that if you feed traffic in half the ports and out the other half, you can go to full media speed simultaneously on each pair of (input, output) ports. Switches also have fancier features than bridges, many of which we’ll be going into in this series of articles.
What is a VLAN?
One of the capabilities switches have added is Virtual LAN’s (VLAN’s). This perhaps started as the ability to group ports according to functionality or business purpose. So some ports would belong to Engineering, others to Accounting.
The reason you’d want to do this goes back to the flooding behavior. A switch has to flood broadcasts (etc.) out all ports. But using VLAN’s, we can group ports so that a broadcast coming in one port in VLAN 1 only gets flooded out the other ports in the same VLAN, and not out ports belonging to other VLAN’s. If you think of a switch or bridge with no VLAN capability as a “dumb switch” or perhaps “basic switch”, then creating VLAN’s is just like dividing a real smart switch into several basic switches, virtual switches.
Since broadcasts pass throughout the VLAN and nowhere else, we can also think of the VLAN as a “broadcast domain”. It is the extent throughout which a broadcast floods. If you have several switches connected together, with grouped ports on each, the broadcast domain may span those several switches.
For comparison, a repeater/hub network is a “collision domain”. There is a length limitation and the hub repeater rule since collision signals need to be reliably detected when two stations simultaneously transmit anywhere in the collision domain. Since bridges and switches operate in store-and-forward fashion (at least logically), the collision domain terminates at a port of a bridge or switch.
That’s how bridges were originally used in designs. By dropping bridges into a network, you’d extend the length of Ethernet cabling without having to introduce a “complex router” (bridge vendor marketing slam).
Switches are of course being used a bit differently. Generally, folks are starting by replacing hubs and bridges with switches. Depending on your traffic patterns, the switch usually instantly grants bandwidth relief, by isolating conversations so that you can have multiple conversations going through the switch at one time, instead of bottlenecking on one.
If you’re still awake, you’re probably thinking, “so why do I need VLAN’s? What’s the big deal if Accounting sees the broadcasts for Engineering?”
The marketing answer to that is security. I’ve always been puzzled by that: not much traffic travels via broadcast, except in very broken protocols or applications. So someone sees my broadcasts? So what?
The more serious answer is perhaps performance. Broadcasts pass through the NIC card on each and every host within the broadcast domain. The host CPU has to examine the MAC layer broadcast to see if it is of interest. It might not be. It might be from another LAN protocol (IPX is useless to an IP-only speaker). It might be a routing update — meaningless to a PC. Etc.
So VLAN’s let you isolate groups sharing broadcasts within your network. If someone in the group goes nuts with broadcasts, multicasts, or unknown unicasts, it only affects their group, not the others. That can be very desirable: one big problem with older bridged networks was that when you had a malfunctioning NIC or application, it tended to take down much or all of the bridged network. I personally wonder how common that was (I wasn’t doing networking back then at any vastly bridged site). Folks from a couple such shops tell me “awful”. It’s clear that when your campus network goes away, it is a highly memorable and unpleasant experience. Conclusion: fault isolation is another important benefit of VLAN’s.
In various Cisco design documents, recommendations as to VLAN size vary: “it depends”. Still, one rough set of numbers is 500 hosts in a broadcast domain, if speakers are using TCP/IP and fairly quiet. The following are not quiet if you are using them: rwho on Suns, or NetBIOS over TCP on PC’s. If using IPX only, consider 300 hosts per VLAN. If AppleTalk or DECnet, maybe 200, since they’re so chatty. I’ll add: Microsoft NetBIOS, probably the same or fewer, depending on how you’re doing it. I’m mentioning these numbers since various folks seem to think they’re good conservative numbers in most situations. If your VLAN’s are bigger, you’re probably fine for now — but may not be later when you introduce more broadcast or multicast into your network, typically for video or conferencing applications.
VLAN’s and Layer 3
One issue that seems to confuse people is how VLAN’s relate to Layer 3 information. The simple answer to that is that a VLAN corresponds to a “logical wire” (well, sometimes “logical switch”), hence an IP subnet. Let’s see how that works.
First we’d better review IP ARP. ARP is a Layer 2 method for relating an IP address to a Layer 2 MAC address. I sometimes think of it as “Layer 2.5”, since it glues the layers together in a sense. When IP speaker A needs to transmit to B within the same subnet, it sends out a MAC layer broadcast. The payload is not an IP packet (read the RFC!) but contains the IP and MAC addresses of the sender, also those of the receiver (with 0’s for the recipient’s MAC address, since the sender doesn’t know it). The MAC broadcast (sent to MAC address ff:ff:ff:ff:ff:ff, the “f-ed address”) is received by all hosts in the broadcast domain. B recognizes its IP address and sends back a unicast reply to A’s MAC address bearing within it B’s IP and MAC addresses. This serves to inform A of B’s MAC address. Then A has the information it needs to be able to build Ethernet headers for transmissions to B.
Suppose you have a subnet somehow split across two VLAN’s. One thing IP hosts need to do before they can communicate is ARP to relate the IP address to a MAC address. Suppose host A in the first VLAN needs to ARP for host B in the second VLAN, both being in the same subnet. Then host A sends a MAC-layer broadcast (trivia question: why is it not an IP broadcast?). But because B is in a different VLAN, hence a different broadcast domain, B will never see the broadcast and therefore will not reply. This results in A being unable to communicate with B.
This means that an IP subnet needs to be contained within one contiguous VLAN. Similarly for Novell networks — think of the VLAN as “the wire” numbered by the IPX network number. And so on for the other Layer 3 protocols.
Could you have two subnets on one VLAN? Well, suppose you have an Ethernet segment, a PLAN (physical LAN) instead of a VLAN. Could you have two subnets on it? Sure — using secondary addresses on the attached router. That might not be quite optimal design, but there are several real-world reasons you might do it.
In summary, one VLAN and one subnet is the simplest. You can have more than one subnet on a VLAN. You cannot split a subnet across separate VLAN’s.
There are three types of devices that need to be configured to interact with VLAN’s: switches (XDI or set-based and IOS-based), and routers. Routers will generally interact with switches across trunks, so we’ll save that piece of the picture for next month’s article.
Really, all we can do at this point is lump switch ports together into VLAN’s. In principle, we cannot even do that, since you have to first create the VLAN, then put the port(s) into it. And creating the VLAN properly belongs with VTP as a topic (next month). Let’s assume for now we’ve got some VLAN’s already created on the switch and that we’re doing some maintenance, maybe in response to user moves/adds/changes.
On the XDI (set-based) switches like the Catalyst 5000’s (2901, 2902, etc.), the command looks like:
set vlan 3 2/1-12
This command puts ports 2/1 through 2/12 into VLAN 3. You could also do something like:
set vlan 4 2/1,4/3
to put ports 2/1 and 4/3 into VLAN 4. To examine what you did there is:
show vlan 3
Here’s the first part of what you’ll see:
Switch> show vlan
VLAN Name Status Mod/Ports, Vlans
---- -------------------------------- --------- ----------------------------
1 default active 1/2
3 engineering active 3/1-6,3/9,3/17-24
1002 fddi-default active
1003 token-ring-default active 3/7-8,3/10-16
1004 fddinet-default active
1005 trnet-default active
On IOS-based switches like the 1912, you instead configure via the menus, via the Web interface, or via IOS command-line interface (CLI). The latter looks like:
interface ethernet 0/6
vlan-membership static 3
The word “static” emphasizes that it doesn’t change, as compared to “dynamic”, which we may get into in a later in an article about VMPS, User Tracking, and the URT software. Note that you configure the interface. If you wonder why they didn’t use the word “port”, I’m told this is more consistent with the IRB bridging configuration in the routers — which will help with consistency as we see more Layer 3 switching. Hint: use the command line editor to do this in sequence to a bunch of ports, umm, interfaces. There is apparently no other easy way to put a whole bunch of them into a VLAN at once. Luckily, you don’t do it very often anyway!
The show vlan-membership command shows ports and what VLAN they’re in, as well as dynamic or static status.
The 2912 and other XL switches use a different IOS syntax. You still configure the interfaces (or use HTTP), but the commands are now:
interface fastethernet 1/2
switchport mode access
switchport access vlan 3
show interface fastethernet 1/2 switchport
Unfortunately, the 29xx XL’s seem to have no equivalents to show vlan and show trunk (see next month’s article), which are darn useful commands on the XDI set-based switches! One hopes this will be fixed in a later software release.
Other models may have slightly different syntax, but you get the idea (and no, I’m not about to go through the documentation for each switch model and build an IOS-dialect translation table for Cisco, unless there’s a lot of popular demand).
In the next article, we’ll look at how VLAN’s get between switches, via trunks. What is a trunk and why do we use them. And we’ll look at Cisco’s VLAN Trunking Protocol, VTP, as well as 802.10, ISL, and 802.1Q. We’ll look at how you configure them and what they’re good for. We may also sneak in a little design: you need to think about end-to-end VLAN’s versus the “Layer 2/Layer 3” hierarchical approach.