VLANs: A reexamination

How is the virtual LAN architecture being extended?

December 1997

Abstract

This month, we provide an overview of VLANs -- where they've been and where they are now. We examine the technologies that have been integrated into multilayer VLANs scenarios and look at how these technologies function in network management. (2,200 words)

Mail this
article to
a friend

n the August 1995 issue of SunWorld, we provided a definition of virtual LANs (VLANs) and the variable speed iterations -- 10-megabits-per-second (mbps) Switched Ethernet, 100BaseT, 100-mbps FDDI -- and the much publicized asynchronous transfer mode (ATM), which offers speeds into the gigabits-per-second range.

In July 1996, we updated the report on VLANs and provided a definition of terms. We again concluded that VLANs were misunderstood and never manageable. In fact, we now conclude that it might be easier to have Microsoft adopt 100% Pure Java than to effectively manage VLANs.

The leading switch vendors are too involved in pitching market lectures for Gigabit Ethernet (now that ATM has fallen aside) to be bothered with figuring out how to manage the technology. The remote monitoring protocol (RMON) vendors are having difficulties scaling to capture data on high-speed ports and are trying to work out coexistence with the leading switch vendors (read Cisco) which ship embedded RMON.

Advertisements

Embedded RMON -- not exactly
There are standalone probes (from companies such as Hewlett-Packard, NetScout, Technically Elite, etc.) and embedded probes from the switch makers (Bay, Cisco, 3Com). The standalone probes offer a dedicated processor for collecting and analyzing network traffic, but they require a dedicated probe, which customers may find costly. On the other hand, switch vendors embed RMON in their hubs, switches, routers, etc. and argue efficiencies of scale.

Most switch vendors only capture RMON groups 1, 2, 4 and 9. According to the RMON specifications (1757 and 1513), they are compatible with the standard. They do, however, provide the functionality of groups 7 and 8 for sophisticated trending and packet capture metrics. Why? Simple. Switch vendors are selling the ability to move packets quickly -- not move packets and manage them. In fact, Cisco has stated that it will not put enhanced RMON (RMON 2 - RFC 2021) functionality in any of its 7000 series and above switches (routers are not trendy anymore). RMON 2 moves RMON up the stack to the network layer which allows RMON to gain exposure across routed segments and filter information at the logical layers of the OSI model.

Back to the future
We now return to August 1995...

With the interconnection of LANs mushrooming and client/server computing taking hold, a new model for the network has emerged. The concept of micro-segmentation began with initial implementation through multiport routers and then with Ethernet switching devices. The router began to run into latency and port density issues as micro-segmenting of the shared media LAN reached its limits. In addition, micro-segmentation through routers strained network administrators as the number of end stations per LAN segment was reduced to lower the overall traffic; at the same time, new IP subnet strategies were needed in order to conserve the subnets available in the registered IP address. Ethernet switching was devised as an alternative link level-based micro-segment strategy, providing dedicated (10-mbps) Ethernet for heavy users. The latter helped relieve overloaded segments, but it could not address the complex traffic patterns in most environments.

Asymmetric traffic patterns coupled with speedier processors continued to load the backbone networks to a point where a higher speed alternative was required. FDDI, Fast Ethernet, and most recently ATM, are now available at more affordable prices to help alleviate the network bandwidth crunch. One size does not fit all, so these tools should be utilized as only part of the total solution. To that end, a description of the attributes of several alternatives will be reviewed in the context of a virtual LAN architecture.

Switched VLANs with high speed aggregates
Virtual LANs, based on switches that provide micro-segmentation for Ethernet environments, must support a high-speed aggregate to allow for a scalable network architecture. Link level-based switches typically utilize an application specific integrated circuit (ASIC) design, and implement VLAN definitions, sometimes called "bridge groups," based on MAC addresses. The advantages of the layer two switch lie in cost and speed (it's primarily implemented in silicone). The bridge group definitions are used to define the boundaries of the broadcast domain while maintaining unique collision domains for each of the switch ports. The link level switch implementations are fast and cheap, but not flexible. This means they do not adapt well to changing network requirements.

Network layer protocols, by definition, are transparent to link layer devices, and, therefore IP subnet boundaries cannot be interpreted by standard Ether-switches. In fact, different workstations with different IP subnet addresses can't communicate through the link layer Ether-switches without the introduction of a router. Because the distributed applications that warranted the introduction of Ether-switches are most likely based on the TCP/IP protocol, it appears that we have come full circle, incurring the added latency of an "edge router" to resolve the addresses from different subnets -- or maybe not.

The multilayer Ether-switch is uniquely comprised of a combination of routing and switching software. A standard routing algorithm like RIP is used to pass traffic between "route groups," but once the routes within a group are learned, IP packets are forwarded through the network layer switching engine. The concept of "virtual subnet" arises from switched connections between different IP subnets. The benefit of this approach is that existing addressing schemes and connectivity preferences can be integrated into the switch configurations, and a hierarchical network design can be supported. A speed benefit is realized over the link level Ether-switch implementation because the function of pure edge routing is eliminated when multiple IP subnets are defined within a single route group.

All of the previously discussed VLAN strategies are based on different applications of the Ethernet connections. These concepts alone do no scale when the traffic pattern follows a more asymmetric model see the Asymmetric Traffic Aside Paradigm diagram. Trying to extend Ethernet to handle a traffic model where all communications converge on a single, high-powered server would be like running a fire hose through a swizzle stick: You just don't get much out the end of that hose. Obviously, high-speed aggregate network connections are needed to address this problem. These high-speed network connections fall into two categories: Shared media and switched media. Shared media like FDDI, CDDI, or 100BaseT, and switched media, like ATM, are very different.

Asymmetric Traffic Aside Paradigm

High-speed shared media alternatives (FDDI, CDDI, or 100BaseT) adapt more easily as a VLAN aggregate for Ethernet because shared media technologies are based on logical 802.x frame definitions. The extension of the VLAN definitions across diverse high-speed media warrants the need for a frame-tracking mechanism in order to ensure the integrity of the workgroup definitions. A 4-byte field in the 802.10 frame has been implemented by a number of vendors as a frame-tagging scheme. This scheme allows multilayer switches and routers to forward to appropriate VLANs based on the 802.10 ID field designator. It should be noted that current implementations of the 802.10 frame-tagging scheme do not utilize the encryption portion of the specification, and are therefore vendor specific. The major argument that vendors like Cisco have against the encryption portion of the specification is that it will add a significant processing load to the switch or router and compromise performance. Until the IEEE 802.10 or some other specification emerges as an industry standard, VLAN frame-tagging schemes will likely remain vendor specific.

Now armed with a multilayer switch vendor of choice and a number of high-speed shared media alternatives, the design concepts of the virtual LAN can be extended to a more asymmetric traffic model. The integration of these new tools allows the virtual network model to scale to handle the bandwidth requirements generated when many clients converge on a single large application server. The following example illustrates a multilayer VLAN scenario, where a 100-mbps FDDI ring is integrated into several VLAN definitions. It should be noted that the route and bridge switch domains have different profiles.

Route group definition
- Group 1 and 3 are assigned the same subnet-based VLAN
  - IP is switched across the FDDI ring
  - IP is switched within each route group
  - Route switching takes priority over bridge groups
  - IP switched access to large application server
- Groups 2 and 4 are assigned different subnet-based VLANs
  - IP is routed between other route groups
  - IP routed access to large application server

Bridge group definitions
- Group 2 and 1 have the shared FDDI port defined
  - Switch non-IP traffic across FDDI
  - Switched access to large application server
- Groups 3 and 4 do not have a shared FDDI port
  - Non-IP traffic is confined to the group
  - No access to large application server

The benefits of this configuration can be seen in lower round-trip delay between subnets in the same route group and in the ability to maintain the current subnet addressing scheme. The network traffic comprised of protocols not configured or capable of being routed communicates via the bridge groups. The bridge group definition serves as a means to limit broadcast domains.

The introduction of the FDDI segment enhances the VLAN definitions by providing a higher speed focal point for the application server and a connection mechanism to extend the bridge and route workgroups across multiple switches. Although FDDI was used in the example, one or more high-speed shared media protocols (like 100BaseT or 100-VG AnyLAN) could have been deployed in addition to or in place of FDDI as the aggregate protocol.

Network management -- VLANs
RMON was developed to look at physical network segments -- not logical segments. To develop statistics on multiple virtual LANs, Lannet (now part of Madge Networks) developed a switched RMON implementation. It allows network administrators to look at statistics across multiple virtual segments. If a segment has a problem, the RMON statistics features can look for more granular information in order to solve it. That's the good news.

While the Lannet approach was helpful, the roving RMON facility required that the administrator be prescient. That is, he or she needed to point the RMON at the logical connection experiencing a problem. The real requirement, for adequate trending and analysis, is to monitor all logical connections. This meant that the RMON had to be embedded in the switch that required high throughput to handle the load. ODS Networks embedded the RMON in its Infinite Switch right into the application specific integrated circuit (ASICs). Then, Joe Head, vice president of engineering, wrote an application, ProtoCop, which captures information from SNMP MIB II, RMON, RMON 2, and third-party enterprise MIBs.

The latter is critical because it allows administrators to view the network in a more holistic sense -- as opposed to SNMP which focuses on single devices. It allows network and system administrators to look at the five areas of management defined by the Open Systems Interconnection (OSI) model. It detects faults, faulty configurations, performance at a network level, accounting, and even security. ProtoCop can detect ongoing intrusions into your network and, in conjunction with ODS hubs, can be configured to limit access at the port level.

Security, in an enterprise sense, is never 100 percent, and it certainly cannot be resolved by throwing a few firewalls at the network. Modems, for instance, can go right around a firewall. A mixture of network access control (which should be part of your global addressing architecture), server access control, and encryption of key applications is essential. ProtoCop detects and details addresses of intruders on your network.

ProtoCop runs on Windows/NT or even Windows 95 and comes with a runtime Access database. Some reports are provided, but the Access database allows individual corporations to tailor the product to their particular needs. Unlike SNMP managers, like HP OpenView, ProtoCop looks more holistically at your networks and systems. It can even detail the inventory of network devices and provide configuration details. (When was the last time your backbone routers were updated with the most recent software?)

With the ease of use of Microsoft Access, ProtoCop can look at networking uptime and provide chargeback information. In addition, service level agreements (SLAs) are suddenly the be all and end all of the computer industry -- other than Java. SLA analysis (the SAP R/3 application was 98 percent available between 8 A.M. and 5 P.M. Monday thru Friday throughout the month of October).

One last notable
In our August 1995 SunWorld article, we quoted Joe Head of ODS. He not only possesses a brilliant and devious mind, he is a hilarious speaker (unheard of in this industry), and we recommend that you attend one of his seminars if the occasion permits. Joe wrote ProtoCop on his own. Who would've thunk a silly switch engineer could write a powerful network and security management application? We live in interesting times.

Who knows -- maybe Scott and Bill will start a weekly golf game with Janet Reno, and Microsoft will decide that Java really is the wave of the future.

Resources

"Have VLANs progressed?" July 1996 SunWorld feature story http://www.sun.com/sunworldonline/swol-07-1996/swol-07-vlan.html
"Stretching the network: VLANs promise a local data superhighway," August 1995 SunWorld feature story http://www.sun.com/sunworldonline/swol-08-1995/swol-08-ethernet.html
"Laying out the virtual network," July 1997 Connectivity column http://www.sun.com/sunworldonline/swol-07-1997/swol-07-connectivity.html
Cisco http://www.cisco.com
NetScout Systems http://www.netscout.com
HP OpenView http://www.hp.com/go/openview
ODS Networks http://www.ods.com
Internet Engineering Task Force http://www.ietf.org
Previous Real World Perspectives columns in SunWorld http://www.sun.com/sunworldonline/common/swol-backissues-columns.html#realworld

About the author
Frank Henderson is chief technology officer at The Netplex Group. His expertise is in designing and installing networks and reengineering help desks, and in ORB, distributed databases, and network management. Dave Koehler is director of network strategies at The Netplex Group. He has 13 years experience in distributed network design. Koehler has written for several journals and has delivered papers at ComNet, IEEE, and SunWorld Expo. Reach Frank Henderson at frank.henderson@sunworld.com and Dave Koehler at dave.koehler@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-12-1997/swol-12-realworld.html
Last modified:

Comments:
Name:
Email:
Company Name: