The collapsed-backbone network
A common LAN network design implemented in the last 10 years or so is called a collapsed backbone. Basically, it connected all floors or rooms in a building to a network where the company's shared servers were located. The typical collapsed-backbone network would look something like Figure A.
Fiber Distributed Data Interface (FDDI) works great as a backbone.
Here you can see that all floors of the building use a fast transport called Fiber Distributed Data Interface (FDDI) as a backbone. FDDI has been around for many years and it works great. The bad news with FDDI comes in the form of expense. In this network, FDDI was connected to the server room on the first floor and created connection points to each floor in the building. Since FDDI is a physical-ring topology, the fiber must connect from the first floor to each consecutive floor and then finally back to the first floor again. A second ring provides redundancy, if warranted.
Each floor has a 10BaseT hub connecting via a twisted-pair cable to the desktop. All this was just peachy and worked beautifully until users started using their desktop PCs for more then just a simple print job or small (<1 MB) file transfers. In the mid 1990s, this design began to result in ghastly network bottlenecks because not only is this network a huge broadcast domain, it's one enormous collision domain as well. That's because FDDI is only a physical-layer topology; it doesn't break up collision or broadcast domains.
The popular solution to this dilemma was the practice of installing bridges on each floor. The new design looked like Figure B.
When each floor has a separate collision domain, network traffic will improve significantly.
Each floor has a 10BaseT hub connecting via a twisted-pair cable to the desktop. All this was just peachy and worked beautifully until users started using their desktop PCs for more then just a simple print job or small (<1 MB) file transfers. In the mid 1990s, this design began to result in ghastly network bottlenecks because not only is this network a huge broadcast domain, it's one enormous collision domain as well. That's because FDDI is only a physical-layer topology; it doesn't break up collision or broadcast domains.
The popular solution to this dilemma was the practice of installing bridges on each floor. The new design looked like Figure B.
When each floor has a separate collision domain, network traffic will improve significantly.
Each floor is now a separate collision domain, which really helped—for a while. But look again—this network is still one immense broadcast domain. As networks grew and more and more network services became available to users, this design became saturated, resulting in lame response time for the users. But by the mid 1990s, Cisco routers became more cost-effective. (Prior to that, they were cost prohibitive for smaller companies, even though they had been available since the late 1980s.)
With the advent of router affordability, the solution to the monstrous broadcast domain issue was to use a Cisco router to break up both collision and broadcast domains. The new and cool network now looked like the one shown in Figure C. The fiber was not discarded but used in point-to-point connections from each floor to the router.
A single router has replaced all the bridges.
With the advent of router affordability, the solution to the monstrous broadcast domain issue was to use a Cisco router to break up both collision and broadcast domains. The new and cool network now looked like the one shown in Figure C. The fiber was not discarded but used in point-to-point connections from each floor to the router.
A single router has replaced all the bridges.
In this network, a single router has replaced the bridges. For many years, I would still find bridges installed at my clients’ locations because the administrators didn't understand the purpose of installing a router—that the router breaks up collision and broadcast domains and that this replaces bridges; it doesn't just add to their functionality. In fact, the bridge, if left in the network, only slowed the network down (created latency issues).
A single router connecting all the floors really worked. As long as users kept their data on the local network 80 percent of the time and only crossed the router 20 percent of the time or less, response time truly soared. This type of network design was implemented worldwide, and Ethernet became the de facto standard that ran to each desktop. But for this design to work properly, that 80/20 rule had to be observed. If the network traffic crossing the router exceeded 20 percent, network response issues would rear their ugly heads once again.
This type of network has been discussed, worked, and reworked. Most of the problems that typically surface have to do with physical location. In other words, for the network to work as designed, you create physical networks and assign subnets to these physical networks. Users are then placed in a physical location by job function. As long as everyone on the same floor performed the same job and shared the same network resources, the network sang. But flies land in the ointment en masse when users with disparate functions and needs are placed on the same floor. The problems created by this scenario can include:
A good solution to this dilemma really didn't exist. There are a few solutions (workarounds) typically configured on the network:
Enter Layer 2 switching and VLANs
Bridges were the precursor to Layer 2 LAN switching. Switches were basically designed to perform the same function as a bridge but with more ports. A typical bridge only had two ports, although you could buy bridges that had up to 16. A LAN switch can have hundreds of ports, and LAN switches are more intelligent.
LAN switches filter the network by hardware address, break up collision domains, provide port security, and can create VLANs. This has changed network design 100 percent from the world of collapsed backbones. Instead of having to worry about creating networks by physical location, VLANs turned the network-design world on its ear by providing options and flexibility like never before to fit any business model. The only design constraint in this type of network is the network administrator's lack of imagination.
Let's take a look at our previous network design and use VLANs instead of routers to break up our networks. Two VLANs were created for this example (see Figure D)
A single router connecting all the floors really worked. As long as users kept their data on the local network 80 percent of the time and only crossed the router 20 percent of the time or less, response time truly soared. This type of network design was implemented worldwide, and Ethernet became the de facto standard that ran to each desktop. But for this design to work properly, that 80/20 rule had to be observed. If the network traffic crossing the router exceeded 20 percent, network response issues would rear their ugly heads once again.
This type of network has been discussed, worked, and reworked. Most of the problems that typically surface have to do with physical location. In other words, for the network to work as designed, you create physical networks and assign subnets to these physical networks. Users are then placed in a physical location by job function. As long as everyone on the same floor performed the same job and shared the same network resources, the network sang. But flies land in the ointment en masse when users with disparate functions and needs are placed on the same floor. The problems created by this scenario can include:
- Users with different job functions sharing the same broadcast domain.
- Anomaly users (those with needs and/or functions not common to a given broadcast domain) required that all their data (packets) cross a Layer 3 device to communicate with the network resources they needed.
- Bandwidth usage quickly became an issue because too many users were placed in the same broadcast/collision domain.
A good solution to this dilemma really didn't exist. There are a few solutions (workarounds) typically configured on the network:
- Adding another broadcast domain by configuring another router port with another hub connected to the floor: This keeps the new users off the existing broadcast domain, but all these new users must still cross a Layer 3 device to get to the network services they use.
- Running a cable from the workstations to the correct broadcast domain: This one actually works pretty well (as long as you don't exceed the distance constraints), but there are dollars involved in running the cables.
- Moving the whole group to another part of the building that has enough room for everyone: Believe it or not, this was the most common solution.
Enter Layer 2 switching and VLANs
Bridges were the precursor to Layer 2 LAN switching. Switches were basically designed to perform the same function as a bridge but with more ports. A typical bridge only had two ports, although you could buy bridges that had up to 16. A LAN switch can have hundreds of ports, and LAN switches are more intelligent.
LAN switches filter the network by hardware address, break up collision domains, provide port security, and can create VLANs. This has changed network design 100 percent from the world of collapsed backbones. Instead of having to worry about creating networks by physical location, VLANs turned the network-design world on its ear by providing options and flexibility like never before to fit any business model. The only design constraint in this type of network is the network administrator's lack of imagination.
Let's take a look at our previous network design and use VLANs instead of routers to break up our networks. Two VLANs were created for this example (see Figure D)
This network is easy to maintain and create security on, and best of all, the physical location of a user is completely irrelevant. Regardless of where users are located, they can be placed in any broadcast domain (VLAN).
Let's take a look at a network design from a client of mine in the San Francisco Bay area. Figure E shows the network design that was in place when I arrived. Hubs were used to connect all the rooms. A fiber connection was used to connect the basement and the 15th floor
Here, 500 users were in the same broadcast domain and collision domain.
Let's take a look at a network design from a client of mine in the San Francisco Bay area. Figure E shows the network design that was in place when I arrived. Hubs were used to connect all the rooms. A fiber connection was used to connect the basement and the 15th floor
Here, 500 users were in the same broadcast domain and collision domain.
The problem with this design is that 500 users were not only in the same broadcast domain but in the same collision domain as well. When they ran out of IP addresses in the network, the administrator just added a secondary network to the router interface. Unfortunately, this is a solution that too many administrators use, and it's a nasty one. Why? Because instead of breaking up collision and broadcast domains, adding a secondary IP subnet to the same broadcast domain just puts more users on the same physical network, making it run like a sleeping mule. Here's the output of the router's interface that had two subnets assigned to the same network:
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0 secondary
ip address 10.1.0.1 255.255.255.0
This customer has an ADSL T1 connection to the Internet, but the connection speed acted more like a 33.6-Kbps dial-up line. This wasn't only because of that secondary network, it was also because of the utter lack of physical network segmentation.
After studying the customer's business requirements by talking with both users and management, I was able to come up with a very cool network that took only a few hours to implement. Figure F shows the new network.
Naming conventions for VLANs often use names of rooms or departments.
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0 secondary
ip address 10.1.0.1 255.255.255.0
This customer has an ADSL T1 connection to the Internet, but the connection speed acted more like a 33.6-Kbps dial-up line. This wasn't only because of that secondary network, it was also because of the utter lack of physical network segmentation.
After studying the customer's business requirements by talking with both users and management, I was able to come up with a very cool network that took only a few hours to implement. Figure F shows the new network.
Naming conventions for VLANs often use names of rooms or departments.
In Figure F, MA through ML are the names of the rooms in the building; I named the VLANs after the rooms. This allowed the administrators to easily identify and locate the VLANs. Also, the IP subnet scheme was designed after the floor and room numbers, since the rooms were also numbered. 151 would be floor 15, room 1. I called the basement floor 1 and created the VLANs as 11, 12, 13, etc. VLAN 1 is the Administrative and Sales VLAN.
The IP network I used was 10.1.x.0/24. The third octet in this design is the subnet number. By looking at an IP address on a machine, the network administrator could tell which floor, room, and VLAN this device was a member of. Cool, huh?
The customer already owned two Cisco 24-port 2900 switches that were bought from a salesman who also sold this customer a dozen or so Cisco FastHubs. Although the Cisco FastHubs are a great product, they're expensive little numbers, and, well, a hub is a hub, folks. I used the hubs in each room to connect all the users and then connected each hub into the switch. I assigned each port to a specific VLAN.
I put one 2900 switch in the basement and configured it as the Virtual Trunk Protocol (VTP) Server. I placed the other 2900 on the 15th floor and put it to work as a VTP Client. That way, the 15th floor 2900 would learn about VLANs from the VTP server. (VTP is a protocol that sends VLAN information between switches.) Doing this really streamlined implementation because it meant I only had to create my VLANs on the basement 2900, which would then broadcast the information to the 15th-floor switch.
Creating VLANs by location more than quadrupled the customer's response time. (This makes you very popular.) Plus, since they already had the switches, this network cost my client very little, was elegantly easy to implement, and was designed to make it very simple for the administrators to add new users. (This makes you extremely popular.) Need selling points for this type of design? It can help:
If you do these things, you can't lose. An important thing to understand in this example is that all users need to get to VLAN 1 because of a shared database. (By the way, I found out this information by asking the users questions about their day-to-day activities before I changed the network.) This means that the users must leave their broadcast domain (VLAN) and get information from the NT Server hosting the database. To do this, I had to configure a router. Luckily, my client already had some good switches and routers. I used the 2600 router to provide Inter-Switch Link (ISL) routing. (ISL routing is a proprietary Cisco method of allowing hosts on different VLANs to communicate through one router interface. Cisco calls this “router on a stick.”) Though this can create a bottleneck for the network, if it becomes a problem, the design allows for an easy upgrade of the router to make the network run even faster.
Here's the output from a 2621 router that shows the ISL configuration:
[output cut]
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
!
interface FastEthernet0/0.11
encapsulation isl 11
ip address 10.1.11.1 255.255.255.0
!
interface FastEthernet0/0.12
encapsulation isl 12
ip address 10.1.12.1 255.255.255.0
!
interface FastEthernet0/0.13
encapsulation isl 13
ip address 10.1.13.1 255.255.255.0
[output cut]
In this configuration, subinterfaces were used to allow all VLANs to be connected to one router interface. In this example, the interface used is FastEthernet 0/0. I made the subinterfaces the same number as the VLAN number for easy identification. The first command under the subinterface is the encapsulation command, which is used to direct the router to the VLAN number of the subinterface and to use ISL inter-VLAN routing.
After the encapsulation command was used to define the VLAN and inter-VLAN routing type (ISL), I added the IP address assigned to the subinterface. The hosts in each VLAN would use the IP address assigned to this interface as their default gateway. For example, users in VLAN 12 would be configured to use 10.1.12.1 as their default gateway. This allowed the users to get out of their own VLAN and to access company shared services, as well as the Internet.
Conclusion
I hope the real-world example I gave you in this Daily Drill Down helped you to understand how valuable using VLAN technology in an internetwork can be and that you now have a clearer picture of how to create them. Even though the largest benefit of creating VLANs in an internetwork is that you are no longer confined to a physical location, this real-life example involved creating VLANs by physical location because that was what was best for the customer.
I can't say enough about how important it is to be fully aware of an individual client's business requirements before you implement any network. Even though I thoroughly discussed the project with every person I could in the company before I performed the upgrade, I still ran into unforeseen problems because the client just forgot to mention a certain application. You can only prepare so much; after that, you must rely on your troubleshooting skills. Hone them well!
The IP network I used was 10.1.x.0/24. The third octet in this design is the subnet number. By looking at an IP address on a machine, the network administrator could tell which floor, room, and VLAN this device was a member of. Cool, huh?
The customer already owned two Cisco 24-port 2900 switches that were bought from a salesman who also sold this customer a dozen or so Cisco FastHubs. Although the Cisco FastHubs are a great product, they're expensive little numbers, and, well, a hub is a hub, folks. I used the hubs in each room to connect all the users and then connected each hub into the switch. I assigned each port to a specific VLAN.
I put one 2900 switch in the basement and configured it as the Virtual Trunk Protocol (VTP) Server. I placed the other 2900 on the 15th floor and put it to work as a VTP Client. That way, the 15th floor 2900 would learn about VLANs from the VTP server. (VTP is a protocol that sends VLAN information between switches.) Doing this really streamlined implementation because it meant I only had to create my VLANs on the basement 2900, which would then broadcast the information to the 15th-floor switch.
Creating VLANs by location more than quadrupled the customer's response time. (This makes you very popular.) Plus, since they already had the switches, this network cost my client very little, was elegantly easy to implement, and was designed to make it very simple for the administrators to add new users. (This makes you extremely popular.) Need selling points for this type of design? It can help:
- Solve your client's problem efficiently.
- Give your client better-than-expected results.
- Save time and money.
- Create something the client can readily understand, control, and scale for growth (making him/her feel competent and confident).
If you do these things, you can't lose. An important thing to understand in this example is that all users need to get to VLAN 1 because of a shared database. (By the way, I found out this information by asking the users questions about their day-to-day activities before I changed the network.) This means that the users must leave their broadcast domain (VLAN) and get information from the NT Server hosting the database. To do this, I had to configure a router. Luckily, my client already had some good switches and routers. I used the 2600 router to provide Inter-Switch Link (ISL) routing. (ISL routing is a proprietary Cisco method of allowing hosts on different VLANs to communicate through one router interface. Cisco calls this “router on a stick.”) Though this can create a bottleneck for the network, if it becomes a problem, the design allows for an easy upgrade of the router to make the network run even faster.
Here's the output from a 2621 router that shows the ISL configuration:
[output cut]
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
!
interface FastEthernet0/0.11
encapsulation isl 11
ip address 10.1.11.1 255.255.255.0
!
interface FastEthernet0/0.12
encapsulation isl 12
ip address 10.1.12.1 255.255.255.0
!
interface FastEthernet0/0.13
encapsulation isl 13
ip address 10.1.13.1 255.255.255.0
[output cut]
In this configuration, subinterfaces were used to allow all VLANs to be connected to one router interface. In this example, the interface used is FastEthernet 0/0. I made the subinterfaces the same number as the VLAN number for easy identification. The first command under the subinterface is the encapsulation command, which is used to direct the router to the VLAN number of the subinterface and to use ISL inter-VLAN routing.
After the encapsulation command was used to define the VLAN and inter-VLAN routing type (ISL), I added the IP address assigned to the subinterface. The hosts in each VLAN would use the IP address assigned to this interface as their default gateway. For example, users in VLAN 12 would be configured to use 10.1.12.1 as their default gateway. This allowed the users to get out of their own VLAN and to access company shared services, as well as the Internet.
Conclusion
I hope the real-world example I gave you in this Daily Drill Down helped you to understand how valuable using VLAN technology in an internetwork can be and that you now have a clearer picture of how to create them. Even though the largest benefit of creating VLANs in an internetwork is that you are no longer confined to a physical location, this real-life example involved creating VLANs by physical location because that was what was best for the customer.
I can't say enough about how important it is to be fully aware of an individual client's business requirements before you implement any network. Even though I thoroughly discussed the project with every person I could in the company before I performed the upgrade, I still ran into unforeseen problems because the client just forgot to mention a certain application. You can only prepare so much; after that, you must rely on your troubleshooting skills. Hone them well!
No comments:
Post a Comment