Home > Articles > Cisco Certification > CCDA > CCDA Self Study: Basic Campus Switching Design Considerations

CCDA Self Study: Basic Campus Switching Design Considerations

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jan 16, 2004.

Case Study and Simulation Exercise

This case study is a continuation of the DJMP Industries case study we introduced in Chapter 2, "Applying Design Principles in Network Deployment."

Key Point: Case Study General Instructions

Use the scenarios, information, and parameters provided at each task of the ongoing case study. If you encounter ambiguities, make reasonable assumptions and proceed. For all tasks, use the initial customer scenario and build on the solutions provided thus far.

You can use any and all documentation, books, white papers, and so on.

In each task, you act as a network design consultant. Make creative proposals to accomplish the customer's business needs. Justify your ideas when they differ from the provided solutions.

Use any design strategies and internetworking technologies you feel are appropriate.

The final goal for each case study is a paper solution; you are not required to provide the specific product names.

Appendix G, "Answers to Review Questions, Case Studies, and Simulation Exercises," provides a solution for each task based on assumptions made. There is no claim that the provided solution is the best or only solution. Your solution might be more appropriate for the assumptions you made. The provided solution helps you understand the author's reasoning and offers a way for you to compare and contrast your solution.

Case Study: Enterprise Campus Design

Complete these steps:

Step 1 You might want to review the DJMP Industries Case Study Scenario in Chapter 2.

Step 2 Propose the optimal campus design that addresses the scenario requirements (switched solution, redundancy, servers in a separate segment, and so on).

Simulation 1: Shared Versus Switched LAN

This exercise is a paper-only version of the simulation that the simulation tool actually performed and includes the results it provided. Review the scenario and simulation results and answer the questions.


The customer (DJMP Industries) plans to restructure its flat campus network, which consists of workstations and servers that are located in the central building and building A. The company is considering Ethernet switching technology as a replacement for the 10BaseT Ethernet hubs. You have been asked to determine what effect the introduction of the switches might have on the load of the links and to estimate the network's responsiveness and utilization with respect to the existing applications.

To provide some proof of future network efficiency, you will model FTP and HTTP performance on the network using shared and then switched Ethernet platforms.

Client Accessing Server in Unloaded Shared Ethernet

The customer has provided the information about its existing network and the number of users. As illustrated in Figure 4-21, you began the initial network behavior evaluation by simulating the load on the LAN links, which was posed by a single client accessing the web server.

Figure 21Figure 4-21 Single Client Accessing Web Server on Unloaded Shared Ethernet

You performed the simulation (using 10-minute intervals), observed the effect of traffic growth, and compared the results among different scenarios.

The relevant statistics of interest for this case are the link (Ethernet) utilization and the HTTP response times.

The graph in Figure 4-22 shows the network load's simulation results that resulted from the HTTP session between the client and the server. The low Ethernet utilization number indicates that the HTTP traffic exchanged between the client and the server does not represent a significant load in the network.

Figure 22Figure 4-22 Ethernet Utilization on Unloaded Shared Ethernet

The graphs in Figure 4-23 show the simulation results of the HTTP response times. On average, the HTTP page response times are within the range of 0.01 and 0.015 seconds, whereas the HTTP object response times vary from approximately 0.004 to 0.01 seconds (every HTTP page consists of several objects).

Figure 23Figure 4-23 HTTP Response Times on Unloaded Shared Ethernet

The graphs in Figure 4-24 show the simulation results of the probability that the HTTP response time is equal to a particular value.

Figure 24Figure 4-24 Probability of HTTP Response Times on Unloaded Shared Ethernett

  1. What can you observe from the graphs in Figures 4-23 and 4-24?

Client Accessing Server in Loaded Shared Ethernet

Your task now is to create a scenario in which the background traffic is simulated to provide a more realistic picture of the ongoing traffic in the network. The client continues to access the web server while all the other clients concurrently initiate FTP sessions to an FTP server; as illustrated in Figure 4-25, a separate FTP server is introduced to eliminate the effect of the server utilization. Therefore, the HTTP session is tested in a heavily-loaded, shared Ethernet network.

Figure 25Figure 4-25 Single Client Accessing the Web Server on Loaded Shared Ethernet

You performed the simulation and compared the results with those from the previous simulation. The graph in Figure 4-26 describes the increased network utilization as a result of the concurrent FTP and HTTP conversations.

Figure 26Figure 4-26 Ethernet Utilization on a Loaded Shared Network

The next step is to observe the HTTP response times again. When examining the graphs in Figure 4-27, you notice that, in general, the results match those that were obtained in the unloaded network. There are some deviations, presumably because of the retransmissions that lower the probability of an immediate response. The delayed responses seem evenly distributed throughout the observed interval.

Figure 27Figure 4-27 HTTP Response Times on Loaded Shared Ethernet

  1. What can you determine from the results? What is the reason for the delayed HTTP responses?

Introducing Switched Ethernet

In the third simulation scenario, the shared Ethernet is replaced with switched Ethernet, which Figure 4-28 shows being implemented with a single LAN switch. The traffic pattern remains the same as in the previous scenario—the client is accessing a web server while all other clients are accessing an FTP server.

Figure 28Figure 4-28 Single Client Accessing the Web Server on Switched Loaded Ethernet

Figure 4-29 shows the results of this simulation. By examining the HTTP response time carefully, it seems that the background FTP traffic does not significantly affect the web communication. Everything is back to normal, the HTTP response times are constantly low, and there is no sign of individual deviations that could compromise the overall statistic numbers.

Figure 29Figure 4-29 HTTP Response Times on Loaded Switched Ethernet

The graph in Figure 4-30 illustrates the probability of receiving a prompt HTTP response. The possibility is almost as high as when a stand-alone HTTP session was simulated (with no background traffic). This leads you to the conclusion that switching technology might be the obvious solution.

Figure 30Figure 4-30 HTTP Response Probabilities on Loaded Switched Ethernet

  1. You concluded that the introduction of the Layer 2 switch represents a significant improvement in this case. How did you determine this from the previous graphs?

Simulation 2: Layer 2 Versus Layer 3 Switching

This exercise is a paper-only version of the simulation that the simulation tool actually performed, including the results the tool provided. Review the scenario and the simulation results and answer the questions.


This simulation inspects the impact of Layer 2 versus Layer 3 switching on the load in various parts of the structured campus network.

After successfully deploying the switching technology, the company is considering further improvements to its campus network design. It has already finished some baseline wiring work in the central building and in Building A and is facing some Layer 2 and Layer 3 design issues.

You decided to model the company's network to match the existing situation using the following architecture:

  • Each building contains distribution-layer switches, to which the access-layer (wiring closet or data center concentrator) switches are connected.

  • The distribution layer devices are connected via two central core switches (the campus backbone).

  • The whole campus is fully redundant.

To provide comparable results, you need a reference traffic flow. Therefore, you decided to focus solely on the communication between the two workstations—WS_A and WS_B—that are located in different floors of building A, and the server in the central building.

Initial Traffic

In the simulation, Workstations A and B communicate with the server using various loads, as illustrated by the graph in Figure 4-31.

Figure 31Figure 4-31 Simulation Load

Layer 2 Only Design

As shown in Figure 4-32, you began the simulation by turning on the Layer 2 functionality on all switches in the campus network. Soon you realized that, even in the highly redundant Layer 2 network, the number of possible paths reduces to only one, as determined by STP. STP computes loop-free networks, and any redundant links belonging to the same LAN or VLAN are placed in the blocking state and cannot be used.

Figure 32Figure 4-32 Layer 2 Only Design

Loaded Network

Figure 4-33 depicts the result of simulating 10 minutes of traffic originated by both workstations toward the server, and vice versa. The average-loaded links (30 percent) appear as solid lines, and the heavily-loaded links (60 percent) appear as dotted lines. The resulting dashed and dotted arrows indicate that the load is not balanced; specifically, all traffic moves over a single path: DS_B _ CS_A _ DC_B.

Figure 33Figure 4-33 Layer 2 Only Loaded Network

Link Failure

Use of redundant links terminating at separate devices helps increase the network's reliability. This is especially true for the observed case, in which you expect that the link or node failure would neither impact the network (at least not for a longer period) nor result in a load imbalance.

To prove this, you studied the effect of the link and node failure on the network performance by tearing down the DS_B _ CS_A link and afterwards disabling the DC_B node. The resulting graph, which is illustrated in Figure 4-34, indicates that the traffic is simply redirected over the alternative path, DS_B __CS_B __DC_A.

Figure 34Figure 4-34 Link Failure on the Layer 2 Only Loaded Network

  1. Does the traffic immediately start using the original path once the link or node has fully recovered?

Layer 3 Switching in Distribution

Next, you decided to replace distribution-layer Layer 2 switches with Layer 3 switches, thereby eliminating the STP path selection restrictions. This was expected to improve the efficiency of the distribution to core link usage.

Figure 4-35 presents the results of the simulation. The traffic is perfectly balanced from the ingress Layer 3 switch all the way to the destination. The sharing is proportional on pairs of source-destination distribution switches, so all the distribution switches are equally loaded (see the arrows representing the load: dotted for average load and solid for heavy load). The access layer contains the only remaining sub-optimal paths.

Figure 35Figure 4-35 Balanced Traffic with Layer 3 Switching in the Distribution Layer

  1. Examining the results in Figure 4-36, you might notice that no load sharing occurs in building A's access layer. Is this a result of the default routing on the workstations using distribution switch DS_A for the primary exit point, or a result of the attached Layer 2 switch placing the secondary port in the blocking mode?

Traffic Flow

The graph in Figure 4-36 shows the path (using thick lines) taken by the packet that is originated by workstation WS_A and destined for the server in the central building. It is obvious that the network resources are used more fairly.

Figure 36Figure 4-36 Traffic Flow from WS_A to the Server

Figure 4-37 shows the path (using thick lines) the packets take in the opposite direction, from the server toward the workstation WS_A. The server uses default routing to send the packets out of the local LAN and therefore does not utilize the redundant path at all.

Figure 37Figure 4-37 Traffic Flow from Server to the WS_A

Failure Resilience

The network is now tested against severe failure events, such as link loss, by simulating a failure of the CS_A _ DC_A link. Figure 4-38 shows the result; the traffic from WS_A to the server is represented by a thick line. As expected, the network does not change its behavior under link failure. The load balancing from the ingress Layer 3 switch to the destination is still perfect, but on a reduced topology. The load distribution ratio on DS_A _ CS_A versus DS_A _ CS_B is 1:2 because the load is shared between distribution-layer next hops.

Figure 38Figure 4-38 Link Failure Scenario Showing WS_A to Server Traffic

Figure 4-39 illustrates the return path from the server to WS_A (shown as thick lines).

Figure 39Figure 4-39 Link Failure Scenario Showing Server to WS_A Traffic

  1. In Figure 4-39, why is the return path completely bypassing the CS_A switch?

Layer 3 Switching in Core and Distribution

At this point, you change the core so that the core and distribution layer switches are all Layer 3 switches. As illustrated in Figure 4-40, the simulated load is perfectly shared from the distribution layer across the core on a hop-by-hop basis.

Figure 40Figure 4-40 Layer 3 Switching Results in a Balanced Load

Load Sharing Under Failure

Next you simulated failure of the link CS_B to DC_B. Figure 4-41 illustrates the resulting path (shown as thick lines) taken by the WS_A traffic to the server. The way the load sharing is done is comparable to the previous case, with the distribution Layer 3 switches and Layer 2 switching in the core.


The actual impact of Layer 3 switches in the core can only be seen if the convergence after the failure is taken into account.

Figure 41Figure 4-41 Link Failure Is Accommodated by WS_A to Server Traffic with the Layer 3 Core

  1. What is the load distribution ratio on DS_A _ CS_A versus the DS_A _ CS_B link in Figure 4-41? Explain.

Layer 3 Access Switch

No load sharing occurs in the access-layer LAN or VLAN if the access-layer switch is a Layer 2 switch and all the workstations use the same default gateway (distribution-layer switch). To achieve load sharing in the access layer, the workstations must be configured to use different next hops (DS_A and DS_B, in this case) for their default routes.

In this scenario, the AS_F1 access-layer switch is upgraded to a Layer 3 switch to achieve more optimal load sharing in the access layer.

Figure 4-42 illustrates the result of the simulation (shown as thick lines): load sharing from AS_F1 toward DS_A and DS_B is perfect.

Figure 42Figure 4-42 Load Sharing in Access the Layer with a Layer 3 Switch

  1. The workstation WS_B is not running any routing protocol; rather, it depends on the default routing. What is a proper next-hop address?

IP Routing Process on the Server

In the last scenario, OSPF is configured on the server. The server starts participating in the campus routing and can rely on OSPF to load-share its traffic toward the workstations.

Figure 4-43 shows the result of the server to WS_A path simulation (shown as thick lines): the load distribution is achieved from the access layer to the destination.

Figure 43Figure 4-43 Load Sharing with the Server Running OSPF

  1. Running a routing protocol is one way to force the server to forward packets to both distribution-layer switches. Can you think of any other option?

6. Review Questions | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020