Have VLANs progressed?
Lack of standards and network management still problematic
July 1996
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Have VLANs progressed?Lack of standards and network management still problematic
|
July 1996
|
Last August in our virtual LAN story, we discussed the pros and cons of VLANs, their scalability, and other networking options. What progress has been made since then? What's happened in terms of higher-bandwidth options, multiprotocol over ATM, VLAN standards, and network management? (2,600 words)
 Mail this article to a friend |
Roger Kosak, project manager for ATM Network Management Integration at IBM and chairman of the ATM Network Management Working Group within the ATM Forum, perhaps said it best: "It is very easy to be captivated by the glamour and elegance of ATM technology and even easier to forget that the technology must be managed."
His statement also applies to VLANs. The industry is still attempting to define them, let alone manage them and provide internetworking (but not interoperability) between vendor implementations.
Segmentation and higher-bandwidth options
With the interconnection of LANs mushrooming and client/server
computing taking hold, a new model for the network has emerged.
The concept of microsegmentation began with initial implementation
through multiport routers and then with Ethernet switching devices.
However, routers ran into latency and port density issues as
microsegmenting of the shared media LAN reached its limits.
Microsegmentation through routers also strained network administrators as the number of end stations on a LAN segment was reduced to lower the overall traffic. At the same time, new IP subnet strategies were needed to conserve the subnets available in the registered IP address. Ethernet switching was devised as an alternative link level-based, micro-segment strategy that could provide dedicated (10 megabits per second) 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. But one size does not fit all -- these tools should be used as 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 microsegmentation for
Ethernet environments, must support a high-speed aggregate 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
media access control (MAC) addresses. The advantages of the layer-two
switch lie in cost and speed since the switch is primarily implemented
in silicon. The bridge group definitions are used to determine
boundaries of the broadcast domain and maintain unique collision
domains for each of the switch ports. The link-level switch
implementations are fast and cheap, but not flexible. They do not adapt
well to changing network requirements.
Network-layer protocols, by definition, are transparent to link-layer devices. IP subnet boundaries cannot be interpreted by standard Ether-switches. In fact, different workstations with different IP subnet addresses cannot communicate through the link-layer Ether-switches unless a router is introduced to resolve communication between different subnets. Since the distributed applications that warranted the introduction of Ether-Switches are likely based on the TCP/IP protocol, it appears we have come full circle by incurring the added latency of an "edge router" to resolve the addresses from different subnets. Or maybe we have not.
The multilayer Ether-switch is uniquely comprised of a combination of routing and switching software. A standard routing algorithm like RIP passes traffic between "route groups" but once the routes within a route group are learned, IP packets are forwarded through the network-layer switching engine. The concept of "virtual subnet" arises from switched connection between different IP subnets. The benefit 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 when multiple IP subnets are defined within a single route group because the function of pure edge routing is eliminated.
All of the previously discussed VLAN strategies are based on different applications of the Ethernet connections. These concepts alone do not scale when the traffic pattern follows a more asymmetric model (See sidebar, Asymmetric traffic paradigm). Extending Ethernet to handle a traffic model where all communications converge on a single high-powered server would be like aggregating a group of fire hoses inta a straw. You just don't get much through a straw; a fire hose would be better. Obviously, high-speed aggregate network fire hoses are needed to address this problem. These fall into two categories: shared media and switched media. Shared media such as FDDI, CDDI, or 100BaseT and switched media like ATM are very different.
High-speed, shared media alternatives like FDDI, CDDI, or 100BaseT adapt more easily as a VLAN aggregate for Ethernet, since 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 to ensure the integrity of workgroup definitions. A 4-byte field in the 802.10 frame has been implemented by a number vendors use as a frame tagging scheme. This scheme allows multilayer switches and routers to connect with 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 therefore are vendor specific. The major argument vendors like Cisco have against the specification's encryption portion 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, 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 and 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-megabit per second FDDI ring is integrated into several VLAN definitions. Note that route and bridge switch domains have different profiles.
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 that is comprised of protocols not configured or capable of being routed communicate via the bridge groups. The bridge group definition server acts as a means to limit broadcast domains.
Introduction of the FDDI segment enhances 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 in the VLAN example.
Multiprotocol over ATM
The ATM Forum has recently formed a new working group that focuses on
the MPOA (multiprotocol over ATM) and virtual router model. The MPOA
concept focuses on using a route server to run the various routing
protocols, calculate optimal routes for the selected network-layer
protocols, and forwards the results to the assigned ATM edge devices
and direct attached stations. The MPOA architecture can be migrated to
a more distributed router server model with the addition of IPNNI
(integrated private-network-to-network interface), which allows
multiple route servers to share network-layer connection images.
Functionally, the route server would intercept the initial packet requiring connection and forward the ATM destination address to the originating multilayer ATM switch. The originating ATM switch would then establish a switched virtual circuit (SVC) connection with the far-end ATM switch, and end-to-end communication would commence. In this scenario, route-server latency was only encountered at the initial connection request and is not present in the remainder of the communication. One conceptual model currently under consideration is to switch packets by protocol-specific virtual connection indentifiers (VCIs). The IPNNI concept can be superimposed on the example by adding more router servers that require IPNNI-based communications to maintain common network-layer images.
The network-layer ATM virtual network conceptual model holds promise for the future but does not provide products that can be used to address networking needs today. The MPOA, IPNNI, and other ATM specification should be followed closely before selecting products to address specific corporate network requirements. ATM truly holds strong possibilities, but as with any new technology, early deployment can be costly.
VLANs -- A standard, please!
Earlier this year, Cisco Systems proposed utilizing the 802.10 LAN/MAN
Security standard as a mechanism for tagging frames with VLAN
identification information. This would allow VLAN switches/routers of
heterogeneous vendors to cooperatively forward packets to the
appropriate virtual LAN. The good news is 802.10 security involves
authentication and encryption techniques for data confidentiality, but
the bad news is that there's a performance hit and an added price.
Even worse, as with SNMP v2, most managers do not have the time or
resource to implement the stringent security requirements.
Cisco backs 802.10 without encryption, but the IEEE 802.10 committee chair insists on including encryption. The 802.1Q committee is not expected to finalize the VLAN standard before the middle of 1997. Cisco says it will adapt its 802.10 implementation to the final standard once it is finalized. In the meantime, users are locked into proprietary interfaces that will not interoperate across vendor platforms.
Fortunately, a new proposal from Bay Networks, 3Com, and others has been adopted by the 802.1Q committee to provide frame tagging without the security requirements of the previous 802.10 committee. The new proposal has received endorsement from Agile Networks, Cisco Systems, Hewlett-Packard, Intel, and others.
On the downside, vendors and vendor consortiums are announcing separate network management strategies (and even some software) for VLANs. Cisco has announced they will roll out its strategy over the next two years. Bay Networks, 3Com, and IBM are rolling out a separate missive, and Cabletron, as usual, has its own unique approach.
Network management -- VLANs and ATM
Remote network monitoring protocol (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,
and if a segment has a problem, then the RMON statistics features can
look for more granular information. That's the good news.
However, there is no agreement on an RMON management information base (MIB) for ATM. Cisco announced earlier this year that it is working with Axon, Frontier, Net2Net, and Network General to develop such a MIB. The ATM MIB allows network managers to collect statistics on the number of ATM cells transmitted, received, received in error, and dropped due to congestion. The proposed standard will also identify different methods for collected traffic information, including the use of circuit steering to direct-selected ATM virtual connections to probes or analyzers. The latter is critical since Cisco has not endorsed embedded RMON in its high-end 7000 series routers due to the performance hit on the processor. Epilogue Technology is now looking at embedding RMON into ASICs to address performance and real-time utilization of the statistics.
There are still problems. First, how much data is there, and how often do you collect it? Once collected, how do you send the information efficiently to one or more management consoles? The problem is the lack of bulk transmission in SNMP v1 which makes the RMON-to-management console transfer a bottleneck. The get bulk command of SNMP v2 would address the problem, but SNMPv2 is still hindered by lack of implementations and the lack of an administrative framework and robust security mechanisms.
On the ATM side, the good news is that the ATM Forum is biting off pieces of the problem. The bad news is this is still an interim plan that does not address end-to-end delivery and does not address the lack of real-time capabilities in SNMP.
It should now be apparent that no one vendor has the total solution, but no two vendors can guarantee interoperability. Before you purchase virtual LAN switches and/or ATM products, make sure you address the following concerns:
|
|
Resources
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright96.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-07-1996/swol-07-vlan.html
Last modified:
Ethernet switching was introduced in 1992 and was hyped as the technology that would save overloaded LAN segments. LAN switches should be more concisely defined as extremely fast multisegment bridges. The initial Ether-switches had limited error correction, no spanning tree support, no network SNMP agents, and limited port count. Since the inception of the original products, full transparent bridging, spanning tree, network management agents, and most recently, error detection have been added. If the main purpose behind the Ether-switch design is to reduce the number of workstations in a given Ethernet collision domain, it may initially appear that these devices have matured to become a staple in standard network architectures. However, several major issues exist with the pure Ether-switching products.
The following example illustrates a common Ether-switching
misconception. The first diagram represents a typical LAN segment
where all users are experiencing response time problems due to excess
contention for the shared media.
The second diagram illustrates a typical Ether-switch-based solution,
where workstation groups have been connected to separate switch
ports. The concept is based on reducing the number of devices that
share a common media. The expected result is a reduction in media
contention and an improvement in response time.
The congestion problem of the above problem has been moved, not
eliminated. Since a typical file server facilitates application
access, file transfers, and printing, most client-originated
communications are destined to the file server. As a result, the
contention problem has moved from the aggregate segment to the server
segment. End users in workgroups A, B, C, and D will realize little or
no response time improvements. This example is intended to clarify a
common Ether-switching misconception that has been propagated since the
technology was introduced. Ether-switches with one or more high-speed
aggregates should be used since they can scale to meet the asymmetric
traffic requirements that are prevalent in most networks.
About the author
Frank Henderson is chief technology officer at The NetPlex Group. He has experience in designing and installing networks, reengineering help desks, ORB, distributed databases, and network management.
Reach Frank at frank.henderson@sunworld.com.