This is Richard's unofficial 100VG AnyLAN WEB FAQ (Frequently Asked Questions) listing for the UseNet news group comp.dcom.lans.ethernet. It is intended to be a source of information regarding VG and a list of answers to the most commonly asked questions about this networking technology.
Also... this document is not a VG verses Ethernet-Token Ring-FDDI-ARCnet-YouNameIt technology. Some comparisons are made, but an honest attempt was made to be objective.
The primary (and preferred) method of distribution is as a WEB document! At first, I had planned to generate an ASCII text version of this FAQ so that it could be directly posted on comp.dcom.lans.ethernet. I gave up on this as it just takes too much time. Sorry. There is no FTP site to retrieve this FAQ. But since it is a Web document, it is easy to download. Just save it to your local drive with your web browser.
Currently, this document is available at http://www.io.com/~richardr/vgfaq.htm.
The table of contents for this document is at http://www.io.com/~richardr/index.html
This list is currently maintained by Richard G Russell. My preferred mail address is richardr@io.com. I live in Austin, Texas a I'm a software engineer, not a sales or marketing guy. If you email me regarding this FAQ, I would really appreciate it if you would use a Subject: line that starts "VG FAQ" so that I can spot FAQ-related emails easily!
This WEB FAQ is currently kept on my primary provider's system Illuminati Online and should be there for a long time. However, it may be mirrored on other Web.
Most of the questions and answers came from my work on a 24 port managed VG hub, from the most recent IEEE 802.12 specification document, and from the other really cool guys and gals at TCC. Since the first version of this document , there has been much lively discussion on comp.dcom.lans.ethernet and I've incorporated much of it here.
In general, any valuable, hard to come by, interesting, helpful, or funny information regarding VG that is spotted in most of the networking-related news groups on the UseNet will be added to this FAQ (sooner or later)! So if you have some interesting VG info, just post it to the net! I'll see it and, if its not already in the FAQ, I'll add it.
If you find an error or horrible omission in this FAQ, the best way to correct it is to just post a POLITE message on comp.dcom.lans.ethernet. I will see it and fix the FAQ. This has the advantage of others seeing the correction when it is made and if the validity of the correction needs to be discussed, it will already be in the best forum for discussion in the world!
However, if you absolutely feel that you must email the maintainer, please include the text of the error and your suggested corrections. The maintainer will then make a concerted effort to verify new info and correct the FAQ. This is especially true if you are a VG guru from HP or AT&T (like a VG chip set designer).
Generally, no. This document is derived from publicly available information and, thus, is in the public domain. However, if you are really greedy and plagiarize this work as your own, you will be flamed unmercifully on the UseNet and everyone will think you are a putz. If no one finds out about it, then like Kurt Cobain says, "when you die you will go to a lake of fire and fry" so there.
Legal-Schmeagle Stuff...
This document is Copyrighted in 1995, 1996, and in 1997 by Richard G Russell. You may distribute this document freely in its un-modified form.
I hate having to copyright this document, but I was advised that it was a good idea by my lawyer.
Nope, not at all. This is a non-vendor specific FAQ. This document is not an attempt to rate equipment from different manufacturers or promote a single vendor's equipment or software more than another. This document is also not a VG verses Ethernet-Token Ring-FDDI-ARCnet-YouNameIt technology. Some comparisons are made, but an honest attempt was made to be objective.
So you say, HEY! My company just built a GREAT VG gizmo and you don't list it! Well, just let me know about and it will be listed! BUT if you decide to tell me about it, then you gotta help me out by sending me all the info you can--like your company's sales telephone number, web page URL's, FTP address, email addresses, fax numbers, nifty company logo gifs or jpegs etc. The more you send me, the more info will be available to others! Just don't forget it's not my job or the purpose of this FAQ to be an advertisement for your company.
I built the main body of this FAQ in one big WEB page (instead of a bunch of little ones) so that it can be easily printed. That's also why there are no color (or complex) graphics in this FAQ.
This is an unofficial FAQ. Its not sponsored by any company or group. I just put it together because, currently, there is very little info on VG out on the net and I like VG and think it's a great technology. I made up a few terms in this FAQ like "Alias Prevention" and "Identity Enforcement" because I couldn't find any already adopted phrases. You will probably not find these phrases (or a few others) in vendor's literature or other places.
I made a concerted and honest effort to be objective. This document is intended to provide technical information regarding VG. It's not intended to be a VG verses "anything else" style of document. It's also not intended to be a sales or marketing vehicle for any specific company. Please take it as it is, and don't read anything else into it.
VG is a new 100 mega bit per second Ethernet and Token Ring networking technology. VG was initially developed by Hewlet Packard and then refined and recently ratified by the IEEE 802.12 committee.
The VG specification (802.12) states that the design goals are to:
In simple English, the goal is to provide a 100 mega-bit networking that provides fair access to the network and to support both Ethernet and Token Ring frame types.
For excellent (though more nitty gritty) info on VG, the 100VG AnyLAN Consortium has a really good document at http://www.iol.unh.edu/training/vganylan/teach/intro.html Their general training page at http://www.iol.unh.edu/training is also chocked full of good stuff!
100VG AnyLAN is based on the IEEE 802.12 standard for transmitting 802.3 Ethernet and 802.5 Token Ring frame information at 100 megabits per second. The 802.2 Standard was ratified on Wednesday, June 14, 1995 at the IEEE Standards Board meeting in Geneva, Switzerland.
The 802.12 committee is also discussing some nifty possible new extensions to VG, such as faster data transfer rates in (400mpbs for copper, and 1gigabit+ for fiber), redundant links between hubs, full duplex links, and burst packet transfers.
AT&T now has both MAC and RMAC (repeater) silicone that supports the Token Ring frame type. TI has a MAC that also supports Token Ring frame type. Expect hubs and cards with token ring frame support from vendors soon (around the first part of '96).
A VG network is made up of hubs and nodes. Each node connects to a port on a hub in a star topology. For example, here is 1 hub with five nodes:
Hubs connect to each other in a tree topology where each hub can have zero, one or more children hubs and zero or one parent hub. The top most hub (the one without a parent) is usually called the root hub.
(nodes omitted for clarity)
Just like most other networks, a VG node can receive a packet at any time but can only transmit at certain times. The set of rules governing when a node can transmit one or more packets on the network are often called media access rules.
The media access rules for VG are called Demand Priority. Other networking technologies, including Ethernet, Fast Ethernet, Token Ring, ARCnet, and FDDI, implement their media access rules in the nodes themselves (there is no central access control). In contrast, all the media access rules for VG are implemented in the hub. The hub, or hubs, decide when each node can transmit. Nodes do not cooperate with each other to decide when they are able to transmit. VG nodes don't pass tokens (even when using Token Ring frame types), or detect and resolve collisions (except when plugged into a 10Base-T hub).
It works like this:
When a node has one or more packets to transmit, it sends a signal (a demand) to the hub that says "hey! let me transmit a packet!" When the hub decides it is time for the node to transmit, the hub sends the node a signal that means "OK! Transmit one packet right now." A node can send a hub two types of transmit requests--normal priority and high priority.
A hub cycles through each of the requesting nodes, in port order, allowing each to transmit one packet. A hub will service each of the nodes asserting a high priority request before servicing any nodes with normal priority requests. It is important to note that the hub pays no attention to nodes that don't need to transmit; they are skipped and do not take time in the hub's round robin algorithm. It is important to note that the round robin scanning is extremely fast and is implemented in hardware by the RMAC chips in the hub.
There two types of transmit demands--normal priority and high priority. This feature is designed to support multi-media video streams or other time-critical applications that require low transmit latency.
To prevent starving normal priority nodes by allowing high priority transmits to hog the network, the hub maintains a priority promotion timer for each node. This timer is started when a node first asserts a normal priority transmit request. If the timer expires before the node gets a chance to transmit, then its request will be upgraded to a high priority request.
In a VG network with multiple hubs, children hubs act as a node to their parent hub. A child hub will signal a request to transmit to its parent hub if any of its children nodes or children hubs need to transmit. The parent hub will then allow the child hub's nodes and/or hubs to transmit their packets
Why do it this way you may ask? Well, the demand priority scheme is designed to improve on the CSMA/CD access method used by 10mpbs Ethernet and 100mpbs fast Ethernet. On a collision-based Ethernet network, a node's access to the network is not deterministic: the time between the point when a packet becomes available to transmit (its the next one the MAC will process) and the time that it actually gets transmitted is not bounded by a calculable maximum. On a VG network, the maximum time a packet will wait to actually get transmitted is bounded by a calculable and measurable maximum for both normal and high priority requests. VG is designed to work well, even under high (90%+) network utilization (often called network load).
Note that this does not mean that the CSMA/CD access method is 'bad' or inferior to Demand Priority, they are just different. Ethernet (10 and 100) networks usually perform quite well. However, there are some instances where Ethernet performance can suffer greatly. VG is designed to work well in these situations. For more information see the sections titled 'Why is Demand Priority a Good Thing' and 'What does "Deterministic" really mean'.
VG, Token Ring and FDDI have similar access characteristics. However, VG has a significant advantage over Token Ring and FDDI--VG nodes that do not need to transmit do not take up any time in the round-robin scanning algorithm. This is in contrast to Token Ring and FDDI where the token must be propagated through a node even if doesn't need to transmit.
The big benefit of DP is that it allocates network bandwidth fairly between all nodes on the network that need to transmit. There are two key ideas here--the notion of fairness and the fact that network bandwidth is divided between only those nodes that need to transmit.
Fairness means that for any given cycle all transmitting nodes get to send exactly one packet. One node (or a small set of nodes) cannot hog a majority of the available network bandwidth.
VG is often compared to Token Ring and FDDI as all three are deterministic in nature (as is Arc Net). However, there is one very, very important difference. There is no token passing in VG! The difference between a token passing network and VG is that on a token passing network, the token must pass thorough each and every node, whether or not it needs to transmit. In other words, the network bandwidth available to each node on the network is directly proportional to the number of stations on the network. As nodes are added to a Token Ring or FDDI network, the bandwidth available to all nodes decreases.
The following formula roughly describes this:
band_width_available = T / node_count
Where T is total bandwidth available on the network. This value is nominally 12 megabytes per second. For more info see these sections "What is the Maximum Ethernet Packet Rate for VG?" and "What is the Maximum Token Ring Packet Rate for VG?".
In contrast, nodes on a VG network that do not need to transmit are completely ignored by the hub (or hubs) on a VG network. In math terms, the following applies:
band_width_available = T / transmitting_nodes <= T / node_count
This means that the minimum (or worst case) bandwidth available to a node on a VG network is determined by the total number of nodes on the network, BUT the bandwidth that is available at any given time is determined by the nodes that need to transmit! Note that this is very similar to the behavior CSMA/CD Ethernet; i.e. when fewer stations need to transmit, more bandwidth is available to those stations that do need to transmit.
However, VG is different from CSMA/CD networks in that for any period of time the minimum network bandwidth available for use by each node on a VG network is easily calculable and guaranteed, where with CSMA/CD networks the available bandwidth to each node can only be estimated and is not guaranteed. This is the difference between a deterministic network (VG) and probabilistic network (CSMA/CD Ethernet). In other words, other nodes can never cause the available bandwidth to a node to fall bellow T / node_count. Note that using high priority can change this, for more info see "How does High Priority Transmits Affect VG Performance".
Ethernet is not deterministic because the media access rules, CSMA/CD, are based on probability. In other words, the time at which any given node can transmit is determined by the behavior of all the other nodes on the network. This isn't as bad as it may sound. As we all know, Ethernet works pretty darn well, especially at network utilization's of 50% and less. In the real world, lightly loaded Ethernet networks scream. However, it is under heavy network utilization (defined here as: when lots of stations need to transmit at the same time) that Ethernet can begin to perform poorly.
Allowing high priority transmits on a VG network changes the deterministic nature of VG drastically. The allocation of network bandwidth between all high priority transmissions and all normal priority transmissions becomes probabilistic (just like CSMA/CD Ethernet). This does not mean that VG loses its deterministic nature: it means the network bandwidth available for normal priority transmissions is dependent on how much high priority traffic there is. Even when there are high priority transmits on VG network, VG still guarantees fair access to the network for all nodes on the network.
In other words, network bandwidth is first distributed evenly to all nodes that have high priority transmit requests pending, and what is left over gets divided evenly between all nodes that have normal transmit requests pending. Only the amount of bandwidth allocated for normal priority transmits becomes probabilistic. Normal transmit requests will still get serviced even if all the network bandwidth is consumed by high priority traffic. This is why the priority promotion timers are there.
It is extremely important to note that high priority transmits should only be used for network traffic that has an exceedingly critical need for low transmit latency delivery, not a need for lots of bandwidth. There is a very big difference between the two.
Transmit latency reefers to the time from when a packet is ready to transmit at the node and the time it actually gets transmitted on the wire is kept very short, i.e., something measured in nano-seconds, not milliseconds.
This can be said another way: "Since Demand Priority already fairly allocates network bandwidth to each node on the network, high priority transmissions should only be used to minimize transmit latency, not allocate bandwidth."
It is quite possible to misuse the high priority feature of VG and lose some of the advantages of running a VG network. This mistake is easy to make since many VG adapter drivers have an option that makes all transmit requests for that node be made at a high priority! DON'T DO THIS! Don't even do it for your server (or servers) on your VG network. If you do, then your network performance will not be optimal. How non-optimal will it be? I don't know, but it won't be optimal....
Here is one example of how this could be misused. Let's say a P90 PCI based server named Camelot is set to always transmit VG packets at high priority and Bob copies a 10 megabyte graphics file (contents left to the imagination...) from Camelot to his workstation. In this case, Camelot is going to send the file as fast as it can to Bob's computer. Camelot is going to keep as many packets queued for transmission as it can (this can be hundreds on a Netware or NT server) and ,thus, will always have at least one packet to transmit. Since the server is the only node that can transmit high priority packets, it will essentially keep all other nodes on the network from transmitting until the entire file is copied (yuck, talk about capture effect).
The upshot of this is that only applications that are written explicitly to use the VG high priority feature should do so, and they should only use high priority to minimize transmission latency, not to artificially "grab" bandwidth.
Recently, I was ask for an equally good example of when High Priority should be used. I can't think of one.
NO! NEVER! There are never any collisions on a VG network. VG does not use carrier detection, collision detection, or collision avoidance as its network access method (CSMA/CD). VG uses an access method called "Demand Priority" to determine when a node may transmit packets on the network.
Usually. Most VG cards have two RJ-45 connectors: one is used to connect to a VG hub and the other is used to connect to a 10Base-T hub. Note that both cannot be used at the same time. When a VG card is plugged into a 10Base-T card, it works just like any other 10 megabit Ethernet card.
This feature is usually used to simplify migration from 10Base-T to 100VG. A network administrator can take his or her time upgrading some or all of the machines on a network with new adapter cards. Users can then be moved to a new VG segment a little at a time or all at once.
Note that some manufacturers may develop cards that only have a VG connection. These cards should be a little cheaper than cards with both types of connections.
No. There are no currently available VG hub products that allow this. There may be some in development, but I seriously doubt it.
When a node (or another hub) gets plugged into a hub, the link between them is trained. Training serves two purposes:
In order to train the link, the two devices exchange a series of special training packets (I'll post the format of these frames at a later date... it's really quite interesting). Packets received by the hub from the training node contain information such as the device type (hub or node), and its operational mode (normal or promiscuous) and the frame type (Ethernet or Token Ring) that the card is programmed to use.
One of the most important things that the hub learns about a node is its MAC address. When a node trains, the hub stores the nodes MAC address in special memory called Content Addressable Memory (CAM). A CAM is essentially an extremely fast (most operate in one or two clock cycles) lookup table. The hub uses its CAM to map the 6 byte IEEE address in a packet's destination address to the port that the device where that address is connected. (See a following section "How do packets move around the network" to see how the CAM is used.)
Link training can happen at any time, not just when a cable is connected or at power up of a node or hub. Training can happen at the request of either the hub or the node itself. A node can cause the link to be retrained to change from normal to promiscuous mode and back again. A hub can force the link to be retrained if it thinks that there is a security problem with that node.
Another reason a node-to-hub link trains is to test the physical connection between the two. The IEEE 802.12 spec says that at least 24 consecutive packets must be received without error by a hub (from a node in training) before the link is activated. So, if you see the 'green light' on a port, then you know the cable is good, and all is well. As you can imagine, this can really help in diagnosing network problems.
Logging into a hub is the process of training and activating the physical link between a hub and a node.
When a packet is received by a hub, it is repeated (simultaneously) to one or more ports according to the following rules:
These rules have two important side effects:
To make it easy to bridge between Token Ring networks and VG Networks. Why would someone want to do this? Well, to migrate some or all of the users on a Token Ring to a screaming fast 100 mega-bit network! (bigger-faster-better.... Wahoo!). Supporting the Token Ring frame type on a VG LAN makes this very easy to do.
The Ethernet and Token Ring frame types are very, very different. It is very difficult (and some say it is impossible) to bridge between the two network types. Well, everyone knows that a Ethernet to VG or a Ethernet to Fast Ethernet bridge is straight forward. Since Fast Ethernet is a 802.3 standard, it does not support the Token Ring frame type, but since VG (802.12) is a completely new standard, the designers were able to take Token Ring into account.
For instance, here is how a simple situation might look.
Note that VG to Token Ring Bridges will need to (and will) support Source Routing and the 802.1d spanning tree specification.
Who makes Token Ring to VG Bridges? Currently nobody (as of November 1995); but expect some real-soon-now. Its interesting to note that when these nifty gizmos become available, they will probably actually be switches, yes a Token Ring to VG switch that supports Source Routing! Cool huh!
No, a entire VG network either uses the Ethernet frame format or Token Ring frame format. Usually, a VG network will run using the Ethernet frame format unless it is being bridged to a Token Ring network. There is no real advantage to running the Token Ring frame type (except for bridging, of course) except that for certain applications node to node throughput might be a little better with the Token Ring frame type as it supports a larger maximum frame size.
Voice Grade. Voice Grade cable usually means Category 3 cable.
No. Since the media access rules of a VG network are implemented in the hub (rather than distributed among the nodes) two VG nodes cannot communicate without a hub.
Currently, VG cards and hubs are available for use over 4-pair Category 3, 4 and 5 wire. Soon, VG will also work over 2 pair shielded twisted pair (like Token Ring) and over fiber. Products for both will probably ship from various vendors toward the end 1995.
The node-to-hub and hub-to-hub cable length limit for 4 pair UTP Cat 3 or 4 cable is 100 meters. The limit for Cat 5 wire is 200 meters. Fiber optic links can be up to 500 meters when 800nm transceivers and 2 kilometers when 1300nm transceivers are used. 2 pair STP links (when available) can be up to 100 meters.
The cable limits for copper cable are due to copper's susceptibility to noise and cross talk. Fiber optic links don't have this problem are limited in length by the time it takes for a signal to travel from one end to the other.
It is important to note that there is no total cable length limit for a VG network. By Contrast CSMA/CD networks (10 and 100megabit Ethernet) have a specification that limits the total amount of cable that can be used in a single
There isn't specified maximum. VG networks can be very, very large. For instance, take a single 24 port hub (23 + 1 uplink) with 23 connected nodes using CAT 5 cable. If each node is at the 200m maximum cable distance from the hub, then the total cable length will be 4,600 meters (yes, 4.6 kilometers). This is a simple example, each node on multiple hubs can each be 200 meters from the hub. As you can see, VG networks can be physically very large.
For more information see the next section.
The maximum copper cable radius is the maximum distance between any two nodes on a VG network. This value is 2,000 meters (2 kilometers). This value is calculated as follows: Take the following VG network with 9 hubs and two nodes.
Each hub is separated by a 200 meter length of CAT 5 cable. Each node (both A and B) are 200 meters from their hubs. There are 10 physical cable segments for a total of 2,000 meters of cable. This is the maximum copper VG cable radius.
Now, since a fiber link between two hubs or a hub and a node can be 2,000 meters itself, it would seem that a VG network could have a radius of up to 18 kilometers. Unfortunately, the maximum VG network radius when using fiber and copper is 2.5 kilometers. This limitation exists because the maximum delay from any node to the root repeater must be less than a specified value (no, I don't know what that is... yet).
Note that this is NOT the maximum amount of total cable that can be in a VG network. There can be much more copper and/or fiber cable in a VG network than 2,500 meters. For instance, let's add some nodes to the above network:
All of the 24 nodes are connected by CAT 5 and are 200 meters from their hubs. The network radius is still 2,000 meters, adding more nodes didn't make the original nodes further apart, but there is 6,400 meters of CAT 5 cable in the network. (24 hub to node links and 8 hub to hub links multiplied by 200 meters).
As you may know, VG uses all four pairs of the CAT 3, 4 or 5 cable that is used to connect nodes to hubs and hubs to hubs. The primary reason for this are the letters 'VG'. 100VG AnyLAN was designed from the outset to run over CAT 3 cable. This cable is commonly called 'Voice Grade' cable (that's where the VG comes from). The reason for this is that there is TONS of CAT 3 installed out there, and the designers of VG wanted to make VG as widely applicable as possible.
Explaining a little about cable will help this discussion. The EIA/TIA Cabling Category Specification provide for the following cable transmission speeds:
On the surface, it would seem that only CAT-5 cable was suitable for 100 megabit networking. While this is true for Fast Ethernet, Copper FDDI and ATM, all of these networking technologies have signaling rates of 100mhz or greater and thus, require CAT-5 cable.
To make VG work over CAT-3, VG uses a 30-MHz clock to transmit 30 Mbit of data on each of the four pairs. This results in an encoded data rate of 120 Mbits per second. Since VG uses a 5B/6B NRZ encoding scheme, this results in an effective bit rate of 100 mega bits per second. The VG Consortium concepts pages at http://www.iol.unh.edu/training/vganylan/teach/vgconcepts/concepts.html describes this in great technical detail.
mmmm..... It says above that CAT-3 is rated for 16mhz and CAT-4 is rated for 20mhz. So how does VG run at 30mhz? Really creative and well designed transceivers. That's how. Watch this space for more information on how this was accomplished! (Its really intense Electrical Engineering stuff and I'm just a lowly software guy).
VG is designed to work over 4 pair Category 3, 4 and 5 cable, i.e., a network link between a node and hub, or a hub and a hub, requires 4 pairs of CAT 3, 4 or 5 wire. All VG products today support all three cable types. However, this cable can come in two forms: bundled and unbundled.
Un-bundled cable for VG consists of 4 twisted pairs of wire (each pair is twisted, not all 8 wires together) in a single sheath. Bundled cable has many twisted pairs (usually 25) in one big sheath. VG can use bundled wire between the hub and nodes. VG cannot use bundled cable for hub to hub connections.
This feature is used to support older Cat 3 cable installations that used bundled cable for telephone use. Most newer cable plants use un-bundled cable and many companies are installing CAT 5 for their new cable plants.
Setting the "Use Bundled Cable" option in your hub should only be done when your cable is bundled! This may sound like obvious advice, but using bundled cable causes a performance hit! The reason is this. Since the pairs in bundled cable are very close together, cross talk and common mode noise is much more of a problem. To minimize problems with noise and cross talk, a VG hub will guarantee that only one packet is in the bundle at any one time. For transmissions this is not a problem. The VG hub only lets one station at a time transmit anyway. For receiving packets, it is a problem. Here is why:
Normally, (when unbundled cable is used) the hub will repeat some packets to more than one node at a time. Take a broadcast or milticast packet for example. When a hub receives a multicast packet, it will repeat that packet to all its nodes, at the same time!
When a hub is connected to its nodes with bundled cable, it cannot do this because of cross talk and noise problems. So, the hub will store the broadcast packet, and send it to each node one at a time! As you can see, this takes a lot longer. This will also happen for normal packets that need to be sent to ports that are in promiscuous mode. This is why using bundled cable with VG is possible, but undesirable. Another thing: if you think you are having performance problems with your VG network, make sure that your hubs are set for operation with unbundled cable!
The answer is "it depends." A VG network is like a 10Base-T Ethernet network. You can hook together lots of hubs. The 802.12 spec says "All topologies that are allowed (in terms of distances and numbers of repeaters) in clause 13 of ISO/IEC 8802-3 for collision domains of 10BASE-T and 10BASE-FL segments are allowed in demand priority access domains."
In English, you can plug together hubs much like 10Base-T hubs are connected. The only practical difference is that a VG network is built in a real tree where intermediate hubs and leaf hubs connect to their parent hubs via their uplink port. A hub's uplink port can plug into any port of its parent hub, except the parent hubs uplink port (i.e., any regular port).
The only real limiting factor in the number of hubs is the number of hub levels in a VG network. The specified limit is 5. In a VG network, there is always a root or level 1 hub. The root hub is either the only hub, or the hub that has one or more children hubs, and no parent hub (nothing plugged into its uplink port). Hubs that do not have other hubs plugged into them are called leaf hubs. Intermediate hubs are the hubs between the root and the leaf hubs. There can be up to three levels of intermediate hubs in a VG network.
A cascade port (also called an up-link port) connects one hub to another hub. A hub always has one and only one uplink port. The uplink port of a hub must connect to a regular port on its parent hub. This port on the parent hub then becomes a downlink port. Note that this link trains just like a node to hub link!
There can be up to 1024 nodes on a single VG segment. However, Hewlet Packard recommends that the practical working limit is 250. Is this a good working limit? Mmmmm...probably. Could a VG network with more than 250 nodes on it work well? Sure.
In short, it depends on your application. Remember, when used properly, VG guarantees a minimum network bandwidth to all nodes on the network and will fairly allocate bandwidth at all times.
In other words, a good understanding of VG and the performance requirements of your network will allow you to put together a VG network that will really work well. (Gee, this is true for any networking technology! _smile_ ).
There are many, many, many different types of network security. VG operates at the data-link level to implement its security features. There are three types of security that can be implemented on a VG Hub.
The following sections address each of these issues.
It is important to note that these security features are specific to the AT&T RMAC chip set which was licensed from Hewlet Packard. Currently, only AT&T sells RMAC chips and all the hubs available use this chip set. While support for these features is built into the AT&T RAMC, it does need a little help from a CPU that controls the hub, so it is possible that not all VG hubs support these features.
It is also possible that these features will not be present or will be implemented in a different way in RMAC chips from other manufacturers when they become available.
These security features are not part of the 802.12 standard. However, these features (or similar features) should be available on all hubs as all hubs use the same AT&T RMAC chips. If other silicone vendors design hub chips, these should also support similar features.
One type of security violation is called "eavesdropping." Normally, a node on a network (Ethernet, Fast Ethernet, Token Ring, FDDI) ignores packets that are not addressed to it. Eavesdropping occurs when a node goes into mode where it receives all packets. This is usually called promiscuous mode and sometimes monitor mode. Often this is a good thing: bridges, routers, and network analyzers must operate in promiscuous mode to do their jobs. However, on a secure network you don't want just anybody to eavesdrop on the network.
The most common ways eavesdropping is exploited is by password capture programs. These programs watch for packets on a network containing passwords--when it sees them, it records them. These passwords can then be used to completely compromise the security on an organization's servers. Don't think that these programs are hard to write or hard to find. They are easy to write, easy to find, and come in many different flavors. Believe it or not, many PC network systems send passwords unencrypted over the network!!!
Lots of other traffic can be snooped as well. File transfers, SQL database queries, and email come to mind easily. Don't think this hasn't been done. It has and the snooping programs will become more sophisticated--believe it.
On Ethernet, Fast Ethernet, Token Ring, and FDDI networks, a node can go into promiscuous mode when ever it is told to by the software on the node. There is no centralized way that this can be prevented. By contrast, this is a simple feat when using VG: just program the hub to prevent one or more ports from going into promiscuous mode! Yup, it's that easy. If the port a node is plugged into has promiscuous mode disabled, then it can not eavesdrop, no matter what kind of software it's running or what kind of adapter is in the machine.
Each node on a Ethernet, Fast Ethernet, Token Ring, FDDI, and VG network has a unique address called its MAC address. A node's (or station's) MAC address is essentially its identity: it is how something receiving a packet knows who the packet is from and to how a send a packet back to its destination.
A network packet has two MAC addresses right at the beginning of the packet. The destination address is the MAC address where the sender wants the packet to go. The source address is the MAC address of the sender and is used by the receiver of the packet as the return address for any messages it needs to send back.
Most adapter cards (or on board chip sets) for Ethernet, Fast Ethernet, Token Ring, and FDDI allow the node's MAC address to be programmed and/or changed on the fly. It is a relatively simple programming task to write software that can send packets with different source MAC addresses. This is called MAC address aliasing
The common question to this is: "So what? How can that be used to compromise a network's security?" Well, the answer is not as obvious as how eavesdropping can be improperly used. MAC address aliasing can be used to trick networking operating systems and clients to do things they would not ordinarily do.
For example, about two years ago, a couple of guys wrote a program called HACK.EXE that used exactly this technique (and eavesdropping) to gain supervisor privileges on a NetWare 3.11 network file server. (Note that Novell quickly provided a patch to plug this security hole). I'm not familiar with any other publicized instances of security breaches using this technique. However, I do know for a fact that it can be used to kill network sessions between clients and servers, and can even be used to crash clients and servers. (No, I'm not going to tell you how to do it.)
Again, this problem is solved easily by VG hubs. When a node trains with (or logs into) a hub, the hub learns its MAC address. From then on, the hub watches each of the packets that the node transmits. Each one had better have a source address that matches the one that the node trained with. If a packet is sent that does not match (has been aliased), then the hub will permanently shut down that port.
Note that alias prevention does not control what MAC addresses can log into a hub on a specific port (or set of ports), but only prevents a station from sending aliased packets. Well, that doesn't sound very useful does it? Well it's not, unless it's used in conjunction with identity enforcement, described in the next section.
Identity enforcement is very similar to alias prevention. They work together hand-in-hand and are of little value unless used together.
Identity enforcement is used to control what nodes (or stations), identified by their MAC address, can log into a hub. A VG hub can examine a node's MAC address during the log in process to control what nodes can log into what ports. A port can be restricted to a single MAC address or to a set of MAC addresses. A hub can also prevent the same MAC address from being used on more than one port.
Identity enforcement and alias prevention are usually just called something like MAC address security (different VG vendors use different catch phrases) as they really must be used together to be effective.
The following reasons illustrate why the security features of VG are effective and are valuable to both the workgroup and enterprise:
Security is a complex problem and good solutions to it will be implemented in layers. VG provides good data-link level security. Data-link security can make it much more difficult for security to be compromised; Here is a simple example:
The fictional plot of a criminal plugging in their powerful, specially programmed lap-top into the corporate net and compromising its security is not far from the truth. On Ethernet and Token Ring (and even FDDI), this is pretty easy. If the criminal can gain physical access to a network port (and possibly just a cable), then nothing can be done to keep the criminal from attaching and eavesdropping on the network. If this occurs, especially if it happens on the secure side of a firewall, there is a high degree of probability that security will be severely compromised.
Using VG can make this more difficult. First, the criminal must somehow obtain the valid MAC addresses for the port he thinks he can get access to. Note that with other networks any port would do, but with VG it must be a specific port. Even if the criminal gets a valid MAC address for a specific port the criminal still can't eavesdrop on the network--an almost essential requirement for compromising most security schemes.
The obvious way around this is to get inside information from a dishonest employee that had access to the information. However this could be difficult and time consuming; more importantly, it increases the criminal's chance of detection.
In short, if the security features of VG should be used in conjunction with other well known security techniques, then a network can be made extremely secure without being too much of a pain in the neck to the people using it.
Answer: 109,890 packets per second when using the Ethernet Frame type.
Here are the calculations: We are assuming that there are two nodes plugged into a single VG hub, and that one node is transmitting to the other (there is only one transmitter). The other assumption is that the packet size is 64 bytes, which is the minimum Ethernet frame format packet size.
( (98+(64*8)) * 10ns) + (3us) ) = 9.1us/packet => 109,890 packets per second!
Note 'us' is micro-seconds, which is 10-6 seconds and a 'ns' is nano-second, which is 10-9 seconds.
Well, 64 byte packets are not very useful. A more useful number is the maximum packet rate for the biggest possible ethernet packet. This allows us to calculate the maximum gross throughput using ethernet frame types. Since the biggest ethernet packet is 1519 bytes
( (98+(1518*8)) * 10ns) + (3us) ) = 125.42us/packet => 7973 packets per second!
This is a maximum gross throughput of about 12 mega bytes per second (1500bytes * 7973pps = 11,959,500bytes/s ). In this calculation, it is important to note the use of the value 1500. This is the maximum data size supported by the ethernet frame type. This means that our 12 mbs factors in the effect of the frame overhead (such as addresses, checksums, lengths, and start of frame and end of frame bit sequences.
More needs to be explained.... (of course). All VG Ethernet frames have the following components:
The '98' in the above equations comes from the start and end of stream bit sequences and the 64 bit frame preamble. 10ns is the bit time at 100 mega-bits/second. 3us is the interpacket gap.
Answer: 184,502 packets per second when using the Token Ring Frame type.
Here are the calculations: We are assuming that there are two nodes plugged into a single VG hub, and that one node is transmitting to the other (there is only one transmitter). The other assumption is that the packet size is 18 bytes, which is the minimum Token Ring frame format packet size. This tiny frame has no data payload at all.
( (98+(18*8)) * 10ns) + (3us) ) = 5.42us/packet => 184,502 packets per second!
Note 'us' is micro-seconds, which is 10-6 seconds and a 'ns' is nano-second, which is 10-9 seconds.
Well, frames with no data payload are not very useful. A more useful number is the maximum packet rate for the biggest possible Token Ring packet. This allows us to calculate the maximum gross throughput using the Token Ring frame type. Since the biggest VG Token Ring packet is 4520 bytes
( (98+(4520*8)) * 10ns) + (3us) ) = 365.58us/packet => 2735 packets per second!
This is a maximum gross throughput of about 12.3 mega bytes per second (4502bytes * 2735pps = 12,312,970bytes/s ). Note that this is about 3% more throughput than when using Ethernet frame types as the bigger frame is more efficient. In this calculation, it is important to note the use of the value 4502. This is the maximum data Payload supported by the VG Token Ring frame type. This means that our 12 mbs factors in the effect of the frame overhead (such as addresses, checksums, lengths, and start of frame and end of frame bit sequences.
More needs to be explained.... (of course). All VG Token Ring frames have the following components:
The '98' in the above equations comes from the start and end of stream bit sequences and the 64 bit frame preamble. 10ns is the bit time at 100 mega-bits/second. 3us is the interpacket gap.
AT&T and TI. AT&T licensed the technology from Hewlet Packard, the original inventors of VG. AT&T makes repeater (RMAC) and adapter (MAC) chips. TI makes the excellent Thunderlan device. The Thunderlan chip is a bus-mastering MAC that supports BOTH VG and FastEthernet!
Motorola has also announced that they will make VG-Mac chips and VG-RMac chips. This technology is also licensed from Hewlet Packard.
Answer: Nowhere.
IEEE documents must be ordered from the IEEE itself. You can contact them at:
Institute of Electrical and Electronic Engineers
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
U.S.A.
(800) 678-IEEE
You can also order information via email to askieee@ieee.org. or see their web site at www.ieee.org
Books:
"Planning and Designing High Speed Networks Using 100VG-anyLAN" by Janis Furtek Costa. ISBN#:0-13-168685-2 Hewlett Packard Professional Books, Prentice Hall Titles
Note: In my opinion, this book is of little value. It was written long before the 802.12 spec was completed and actually contains some erroneous information! It also doesn't contain much useful information. You will find better info at the UNH and here, in this FAQ.
Two case studies of 100VG installations have appeared recently:
LAN Times, Feb 13, 1995, "Network Calls for 100 Mbps; Manager goes to 100VG-AnyLAN to process 40 GB hourly", Michelle Rae McLean
Communications News, May 95, "100VG Speeds Up Busy University Research Network"
LAN Times, Jan 5 1995, "Shopping for a High-Speed Vehicle"
VAR Business, Sept 15, 1995, "Solving the High-Speed Networking Puzzle"
Current Version:
V1.3 Saturday, February 22, 1997
Revision History:
V1.2 Sunday, January 28, 1996
V1.1 Friday, November 3, 1995
V1.0 Sunday, August 6, 1995