yazik.info Physics Ccde Study Guide Pdf


Tuesday, April 2, 2019

Mar 21, Yusuf Bhaiji – Learning and Development Manager required for CCDE), but do not limit your study to CCDA/CCDP material. What is it in the nature of reality and of mind that makes self- esteem an urgent concern? This is where our inquiry be CompTIA Linux+ Study yazik.info CCDE Study Guide - Ebook download as PDF File .pdf), Text File .txt) or read book online. CCDE.

Ccde Study Guide Pdf

Language:English, Spanish, German
Published (Last):25.09.2015
ePub File Size:24.53 MB
PDF File Size:20.13 MB
Distribution:Free* [*Register to download]
Uploaded by: DEMETRIA

The design topics covered in this CCDE Study Guide aim to prepare you to be able to. □ Analyze and Therefore, you can use this book as an all-in-one study guide covering the various networking configuration/guide/vfc38/yazik.info . The authoritative, business-driven study resource for the tough CCDE Practical Exam. CCDE Study Guide is written and reviewed by CCDE engineers and helps . Agenda. • High Level View. • CCDE Update. • CCDE Written Exam. • CCDE Practical Exam + demo. • Cisco Learning Network (CLN). • Cisco Press.

Design goal simplicity versus scalability versus stability Network topology Network size nodes. Note Link state can offer built-in information hiding capabilities route suppression by using different type of flooding domains.

How many layers should we consider in our design? How many modules or domains is good practice? The simple answer to these questions depends on several factors. The subsequent sections examine where and why to break a routed network into multiple logical domains. By applying this concept to the design of logical routing architectural domains. Dividing a network into multiple flooding domains. You will also learn summarization techniques and some of the associated implications that you need to consider.

To achieve this. Note Although route filtering can be considered as an option for hiding reachability information. In a multiple flooding domain design with OSPF.

OSPF has a hard edge at the flooding domain borders. IS-IS routing information of the different levels L1 and L2 is technically carried over different packets. The natural communication behavior of link-state protocols across multiple flooding domains requires at least one router to be dually connected to the core flooding domain backbone area and the other area or areas.

In IS-IS. In OSPF terminology.

CCDE Study Guide

This makes it more flexible than OSPF. This helps IS-IS have a softer edge at its flooding domain borders. This will result in communication isolation between the London and Sydney data centers. Although an OSPF virtual link can help to fix partitioned backbone area issues. IS-IS can perform better when optimal routing is required with multiple border routers. It is considered a poor design because the OSPF backbone area has the potential to be partitioned if the direct interconnect link between the regional data centers London and Sydney fails.

Based on the current OSPF area design. OSPF will consider this link as a point-to-point link. Figure illustrates the logical view of OSPF areas before and after the failure event on the data center interconnect between London and Sydney data centers. As shown in Figure This is more of a concern when the interconnection is a low-speed link such as legacy WAN link time-division multiplexing [TDM] based. What is the maximum number of routers that can be placed within a single area?

The common rule of thumb specifies between 50 and routers per area or IS-IS level. Hardware resources such as memory. Although this may introduce other design limitations with regard to modern architectures. Frame Relay. This can have a major influence on the design. Note The solution presented in this scenario is based on the assumption that traffic flowing over multiple international links is acceptable from the perspective of business and application requirements.

EIGRP has no protocol-specific flooding domains or structure. This is a foundation and can be expanded if the design requires more areas per ABR.

In addition to these facts and variables. EIGRP offers a higher degree of flexibility and scalability in networks with three and more levels in their hierarchies as compared to link-state routing protocols [19].

EIGRP with route summarization or filtering techniques can break the flooding domains into multiple hierarchies of routing domains. With the next generation of routers. ABRs can hold a greater number of areas. This concept is a vital contributor to the optimization for the overall EIGRP design in terms of scalability. Analysis and Design Principles. Routing Domain Logical Separation The two main drivers for breaking a routed network into multiple logical domains fault domains are the following: Network designers need to consider these when designing or restructuring a routed network.

The considerations discussed in the sections that follow are the primary influencers that help to determine the correct location of the logical routing boundaries.

These two drivers enhance network convergence and increase the overall routing architecture scalability. As such. Routers A and B and routers C and D are good potential points for breaking the routing domain physical aggregation points. Underlying Physical Topology As discussed in Chapter 1. It is critical to decide where a routing domain can be divided into two or multiple logical domains. Figure Topology Depth Moreover. This concept will promote a design that can facilitate the support of other design principles.

Figure Physical Aggregation Points The other important factor with regard to the physical network layout is to break areas that have a high density of interconnections into separate logical fault domains where possible. This will ultimately lead to the reduction of the overall control plane design complexity [8]. LSDB and will only compute paths within their fault domain. The logical topology can be broken using OSPF areas.

IS-IS levels. This means the network may be less scalable and associated with lower control plane stability because routers E and F will have a full view of the topology of the regional data center network connected to routers G and H. OSPF always prefers the path over the same area regardless of the link cost over other areas.

Traffic Pattern and Volume By understanding traffic pattern for example. Figure Potential Routing Domain Boundaries The network illustrated in Figure has four different functional areas: The primary data center The regional data center The international WAN The hub-and-spoke network for some of the remote sites From the perspective of logical separation.

For more information about this. The question you might be asking is this: Why has the domain boundary been placed at routers G and H rather than router D? Traffic sourced from router B going to the regional data center behind router G should optimally go through router D.

Figure Traffic Patterns Similarly. The third point here is traffic pattern. If you apply the concepts discussed in this section. This can simplify summarization and introduce modularity to the overall logical architecture.

Based on this analysis. It is obvious that there will be traffic from the remote sites to the regional data center. This suboptimal routing results entirely from the poor design of OSPF areas. Routers C and D are the points where the access. The important point here is that the physical layout of the topology must be taken into account. Figure IS-IS Levels and Optimal Routing Route Summarization The other major factor when deciding where to divide logical topology of a routed network is where summarization or reachability information hiding can take place.

Route Summarization By having a well-structured IP address align with the physical layout with reachability information hiding using routes summarization. Subsequent sections in this chapter cover route summarization design considerations in more detail. Security Control and Policy Compliance This pertains more to what areas of a certain network have to be logically separated from other parts of the network.

This means less memory. In some situations. Figure illustrates a network with unstructured IP addressing. The following subsections discuses summary suboptimal routing and summary black-holing in more detail. The reason why summarization might not always be considered at the logical boundary domain is because in some designs it can lead to suboptimal routing or traffic black-holing also known as summary black holes. Figure Unstructured Physical Connectivity As a general rule of thumb not always.

Based on this design. This principle can optimize many network designs. Summary Black Holes The principle of route summarization is based on hiding specific reachability information. The nonsummarized link can be used as an alternate path to overcome the route summarization black-holing issue described previously. In the scenario illustrated in Figure Figure Summary Black Hole Optimization Suboptimal Routing Although hiding reachability information with route summarization can help to reduce control plane complexity.

This suboptimal routing. This behavior will cause suboptimal routing for traffic destined to London data center network. In this particular scenario. As illustrated in Figure This is in addition to the extra cost and delay that will from the traffic having to traverse multiple international links. It can apply to all routing protocols in general. This suboptimal routing in turn can lead to an undesirable experience.

Even so. Based on the these design considerations and scenarios. IS-IS Typically. Level 2 3. Level 1 2. Inter-area routes 3. This process is also known astraffic engineering. OSPF If multiple routes cover the same network with different types of routes. From a routing point of view. If multiple paths cover the same network with the same route type and cost.

Level 2 external with internal metric type 4. Level 1 external with external metric type. OSPF will typically select all the available paths to be installed in the routing table. Summary By understanding the variables that influence a routing protocol decision to select a certain path.

Note with IS-IS. Intra-area routes 2. External type 1 routes 4. Table summarizes the characteristics of the IGPs. For more stability and simplicity. Like other IGPs. There are two primary forms of BGP peering: The peering between BGP neighbors that occurs between the boundaries of different autonomous systems interdomain Interdomain Routing Typically. Table Interdomain Routing Terminologies. The typical example is the global Internet. The powerful policies of EGP allows it to ignore several attributes of routing information that typically an IGP takes into consideration.

Unlike an IGP where routing is usually performed based on protocol metrics to determine the desired path within an AS. Table summarizes common AS terminology with regard to interdomain routing concept and as illustrated in Figure BGP is almost always the preferred inter-AS routing protocol. The larger the mesh becomes. Note In Table BGP is considered as the routing protocol of the global Internet.

EGP relies more on policies to route or interconnect two or more autonomous systems. Unlike IGPs. This is because the nature of full-mesh topology is not very scalable. According to RFC BGP is considered the de facto routing protocol for the global Internet and large-scale networks. Inbound interdomain routing policy to influence which path egress traffic should use to reach other domains Outbound interdomain routing policy to influence which path ingress traffic sourced from other domains should use to reach the intended destination prefixes within the local domain Transportation interdomain routing policy to influence how traffic is routed across the transit domain as well as which prefixes and policy attributes from one domain are announced or passed to other neighboring domains.

QoS scheme. This information describes the characteristics of a BGP prefix. Figure Interdomain Routing Furthermore. BGP has the most flexible and reliable attributes to match the various requirements of interdomain routing and control.

Prefer oldest route for eBGP paths Prefer shortest AS path 5. There are four primary types of BGP attributes. Prefer highest weight Cisco proprietary. These attributes are critical and effective when designing BGP routing architectures. Prefer the path through the closest IGP neighbor 9. Prefer highest local preference global within AS 3.

A good understanding of these attributes and their behavior is a prerequisite to produce a successful BGP design. Prefer route originated by the local router 4. BGP primarily relies on these attributes to influence the process of best path selection. Convergence time: Enterprise Core Routing Design Models with BGP This section highlights and compares the primary and most common design models that network designers and architects can consider for large-scale enterprise networks with BGP as the core routing protocol as illustrated in Figure through Figure To achieve that.

This might not always an acceptable or supported practice by the business. BGP in the enterprise core can offer the following benefits to the overall routing architecture: A high degree of responsiveness to new business requirements. In both cases. Staff knowledge and operational complexity: BGP in the enterprise core can simplify the routing design.

These design models are based on the design principle of dividing the enterprise network into a two-tiered hierarchy. BGP is the ideal candidate protocol as the enterprise core routing protocol. This hierarchy includes a transit core network to which a number of access or regional networks are attached. Hardware and software constraints: Some legacy or low-end network devices either do not support BGP or may require a software upgrade to support it.

In this design model. Design model 1: BGP is used across the core and regional networks. Reachability information is exchanged between each regional network and the core over eBGP no direct BGP session between regional networks. Regional networks use IGP only. MPLS is enabled across the core.

Ccde Study Guide

Reachability information is exchanged between the regional networks directly over direct eBGP sessions. BGP is used across the regional networks. During the planning phase of network design or design optimization. The question is this: How can router A decide which path is the shortest optimal within the enterprise core AS ? AIBGP replicates the behavior of link-state routing protocols in computing the distance associated with a path that has routes within a single flooding domain.

Prefer highest local preference global within single AS 3. Prefer shortest AS path 6. Prefer lowest AIGP cost 5. According to the default behavior of BGP. This means that a full mesh of iBGP peering sessions is required to maintain full reachability across the network. RRs reflect routes to nonclient iBGP peers as well. BGP has two main proven techniques that you can use to reduce or eliminate these limitations and complexities of the BGP control plane: RR clustering is designed to provide redundancy.

BGP RR can introduce new challenges that network designers should take into account. These points are covered in the subsequent sections. RRs can introduce a single point of failure to the design if no redundancy mechanism is considered. With RR clustering. If the redundant RRs are being deployed in different clusters.

They should be as congruent as possible to avoid any undesirable behaviors. Figure RR Clustering In contrast. RR C will advertise it to data center aggregation router F. Data center aggregation F will have next hop to prefix Based on the design in Figure Note For simplicity. Up to this stage. Based on physical connectivity and IGP. Because data center aggregation F has prefix Routing Loop This loop was obviously formed because there is no alignment congruence between iBGP-RR topology and the physical topology.

It might take a long time to provision a fiber link. The following are three simple possible ways to overcome this design issue and to continue using RRs in this network: Add a physical link directly between E and D and between F and C. Data center aggregation E will forward the packets destined to prefix This point is covered in more detail later in this book.

Update Grouping Update grouping helps to optimize BGP processing overhead by providing a mechanism that groups BGP peers that have the same outbound policy in one update group. Note One of the common limitations of the route reflection concept in large BGP environments is the possibility of suboptimal routing.

By integrating this function with BGP route reflection. The BGP communication between these sub. The typical solution to this dilemma. Confederation Versus Route Reflection The most common dilemma is whether to use route reflection or confederation to optimize iBGP scalability.

Table highlights the different factors that can help you narrow down the design decision with regard to BGP confederation versus route reflection. RFC Route redistribution is one of the most advanced routing design mechanisms commonly relied on by network designers to achieve certain design requirements. As a designer. Merger and acquisition scenarios. In large-scale networks. This behavior is described as a nontransitive attribute. Single redistribution boundary point Multiple redistribution boundary points Single Redistribution Boundary Point This design model is the simplest and most basic route redistribution design model.

Note None of the preceding points can be considered as an absolute use case for route redistribution. That is why network designers must have a good understanding of the characteristics of the participating routing protocols and the exact aim of route redistribution. Route redistribution can sometimes be as simple as adding a one-line command. Figure Nontransitive Attribute of Route Redistribution. This is based on the assumption that there is no other redistribution point between the same routing domains anywhere else across the entire network.

Route redistributions can also be used as an interim solution during the migration from one routing protocol to another. Route redistribution can sometimes facilitate routing integration between different organizations.

The issue in this scenario is that when the same route is redistributed back into the RIP domain with a lower metric for example. RIP relies on hop counts to determine the best path. Router B will redistribute this route into the OSPF domain with the default redistribution metrics or any manually assigned metric.

OSPF assigns a default metric value to the redistributed external route. The primary issues that can be introduced by this design are as follows: Routing loop Suboptimal routing Slower network convergence time To optimize a network design that has two or more redistribution boundary points. Metric transformation Administrative distance Metric Transformation Typically. Multiple Redistribution Boundary Points Networks with two or more redistribution boundary points between routing domains require careful planning and design prior to applying the redistribution into the production network.

Because of the different metrics measures used by each protocol. AD can be a concern that requires special design considerations. R10 is. If for any reason AD tuning is used. Figure Multipoint Routing Redistribution Hypothetically. You can tune AD value to control the preferred route. Administrative Distance Some routing protocols assign a different administrative distance AD value to the redistributed route by default typically higher than the locally learned route to give it preference over the external redistributed route.

From the route redistribution design point of view. To resolve this issue. Route Filtering Versus Route Tagging with Filtering Routing filtering and route tagging combined with route filtering are common and powerful routing policy mechanisms that you can use in many routing scenarios to control route propagation and advertisement and to prevent routing loops in situations where multiple redistribution boundary points are exits with mutual route redistribution between routing domains.

With route filtering combined with tagging. Figure Multipoint Route Redistribution: This design has the following technical concerns: At the other redistribution boundary point again R1 and R2 routes can be stopped from being redistributed into EIGRP again based on the assigned tag value. After you apply this filtering, the loop will be avoided, and path selection can be something like that depicted in Figure With route tagging as in this example, network operators do not need to worry about managing and updating complicated access control lists ACLs to filter prefixes, because they can match the route tag at any node in the network and take action against it.

Therefore, this offers simplified manageability and more flexible control. The optimal path, however, will not be guaranteed in this case unless another local filtering is applied to deny the EIGRP route from being installed in the local IS-IS routing table of the boundary routers. However, this must be performed only if optimal path is a priority requirement, to avoid impacting any potential loss.

For instance, if R1. From design point of view, achieving optimal network design does not mean optimal path must always be considered. For instance in the scenario discussed above, if the IS-IS domain is receiving a default route from an internal node such as an Internet edge router.

Because, optimal path can introduce design and operational complexity as well as it may break the internet reachability in this particular scenario. Enterprise Routing Design Recommendations This chapter discussed several concepts and approaches pertaining to Layer 3 control plane routing design.

Table summarizes the main Layer 3 routing design considerations and recommendations in a simplified way that you can use as a foundation to optimize the overall routing design. Determining Which Routing Protocol to Use In large-scale enterprise networks with different modules and many remote sites, selecting a routing protocol can be a real challenge.

Therefore, network designers need to consider the answers to the following questions as a foundation for routing protocol selection: What is the underlying topology, and which protocol can scale to a larger number of prefixes and peers?

Which routing protocol can be more flexible, taking into account the topology and future plans for example, integrating with other routing domains? Is fast convergence a requirement? If yes, which protocol can converge faster and at the same time offer stability enhancement mechanisms?

Which protocol can utilize fewer hardware resources? Is the routing internal or external different routing domains? Which protocol can provide less operational complexity for instance, easy to configure and troubleshoot? Although these questions are not the only ones, they cover the most important functional requirements that can be delivered by a routing protocol.

Furthermore, there are some factors that you need to consider when selecting an IGP: In contrast, BGP is the preferred protocol to communicate between different routing domains external , as summarized in Figure Moreover, the decision tree depicted in Figure highlights the routing protocol selection decision to migrate from one routing protocol to another based on the topology used.

This tree is based on the assumption that you have the choice to select the preferred protocol. Summary For network designers and architects to provide a valid and feasible network design including both Layer 2 and Layer 3 , they must understand the characteristics of the nominated or used control protocols and how each behaves over the targeted physical network topology.

This understanding will enable them to align the chosen protocol behavior with the business, functional, and application requirements, to achieve a successful business-driven network design.

Also, considering any Layer 2 or Layer 3 design optimization technique such as route summarization may introduce new design concerns during normal or failure scenarios such as suboptimal routing. Therefore, the impact of any design optimization must be taken into consideration and analyzed, to ensure the selected optimization technique will not induce new issues or complexities to the network that could impact its primary business functions.

Ideally the requirements of the business critical-applications and business priorities should drive design decisions. Enterprise Campus Architecture Design A campus network is generally the portion of the enterprise network infrastructure that provides access to network communication services and resources to end users and devices that are spread over a single geographic location.

It may be a single building or a group of buildings spread over an extended geographic area. Normally, the enterprise that owns the campus network usually owns the physical wires deployed in the campus. Moreover, enterprises can also have more than one campus block within the same geographic location, depending on the number of users within the location, business goals, and business nature.

When possible, the design of modern converged enterprise campus networks should leverage the following common set of engineering and architectural principles [10]: Hierarchy Modularity Resiliency. Enterprise Campus: Hierarchical Design Models The hierarchical network design model breaks the complex flat network into multiple smaller and more manageable networks. Each level or tier in the hierarchy is focused on a specific set of roles.

This design approach offers network designers a high degree of flexibility to optimize and select the right network hardware, software, and features to perform specific roles for the different network layers. A typical hierarchical enterprise campus network design includes the following three layers: Core layer: Provides optimal transport between sites and high-performance routing.

Due the criticality of the core layer, the design principles of the core should provide an appropriate level of resilience that offers the ability to recover quickly and smoothly after any network failure event with the core block. Distribution layer: Provides policy-based connectivity and boundary control between the access and core layers. Access layer: The two primary and common hierarchical design architectures of enterprise campus networks are the three-tier and two-tier layers models.

Three-Tier Model This design model, illustrated in Figure , is typically used in large enterprise campus networks, which are constructed of multiple functional distribution layer blocks. Two-Tier Model This design model, illustrated in Figure , is more suitable for small to medium-size campus networks ideally not more than three functional disruption blocks to be interconnected , where the core and distribution functions can be combined into one layer, also known as collapsed core-distribution architecture.

Note The term functional distribution block refers to any block in the campus network that has its own distribution layer such as user access block, WAN block, or data center block. Modularity By applying the hierarchical design model across the multiple functional blocks of the enterprise campus network, a more scalable and modular campus architecture commonly referred to as building blocks can be achieved.

This modular enterprise campus architecture offers a high level of design flexibility that makes it more responsive to evolving business needs. As highlighted earlier in this book, modular design makes the network more scalable and manageable by promoting fault domain isolation and more deterministic traffic patterns.

As a result, network changes and upgrades can be performed in a controlled and staged manner, allowing greater stability and flexibility in the maintenance and operation of the campus network. Figure 33 depicts a typical campus network along with the different functional modules as part of the modular enterprise architecture design. Note Within each functional block of the modular enterprise architecture, to achieve the optimal structured design, you should apply the same hierarchal network design principle.

When Is the Core Block Required? A separate core provides the capability to scale the size of the enterprise campus network in a structured fashion that minimizes overall complexity when the size of the network grows multiple campus distribution blocks and the number of interconnections tying the multiple enterprise campus functional blocks increases significantly typically leads to physical and control plane complexities , as exemplified in Figure In other words, not every design requires a separate core.

For instance, it is rare that a typical small to medium-size remote site requires a three-tier architecture even when future growth is considered.

In contrast, a regional HQ site or a secondary campus network of an enterprise can have a high potential to grow significantly in size number of users and number of distribution blocks. Therefore, a core layer or three-tier architecture can be a feasible option here. This is from a hypothetical design point of view; the actual answer must always align with the business goals and plans for example if the enterprise is planning to merge or acquire any new business ; it can also derive from the projected percentage of the yearly organic business growth.

Again, as a network designer, you can decide based on the current size and the projected growth, taking into account the type of the targeted site, business nature, priorities, and design constraints such as cost. For example, if the business priority is to expandwithout spending extra on downloading additional network hardware platforms reduce capital expenditure [capex] , in this case the cost savings is going to be a design constraint and a business priority, and the network designer in this type of scenario must find an alternative design solution such as the collapsed architecture two-tier model even though technically it might not be the optimal solution.

That being said, sometimes when possible you need to gain the support from the business first, to drive the design in the right direction. Consequently, this may help to influence the business decision as the additional cost needed to consider three-tier architecture will be justified to the business in this case long-term operating expenditure [opex] versus short-term capex.

In other words, sometimes businesses focus only on the solution capex without considering that opex can probably cost them more on the long run if the solution was not architected and designed properly to meet their current and future requirements. Technically, each design model has different design attributes.

Therefore, network designers must understand the characteristics of each design model to be able to choose and apply the most feasible model based on the design requirements.

The list that follows describes the three primary and common design models for the access layer to distribution layer connectivity. The main difference between these design models is where the Layer 2 and Layer 3 boundary is placed and how and where Layer 3 gateway services are handled: Classical multitier STP based: This model is the classical or traditional way of connecting access to the distribution layer in the campus network.

In this model, the access layer switches usually operate in Layer 2 mode only, and the distribution layer switches operate in Layer 2 and Layer 3 modes. For more information, see Chapter 2. Routed access: In this design model, access layer switches act as Layer 3 routing nodes, providing both Layer 2 and Layer 3 forwarding. In other words, the demarcation point between Layer 2 and Layer 3 is moved from the distribution layer to the access layer.

Based on that, the Layer 2 trunk links from access to distribution are replaced with Layer 3 point-to-point routed links, as illustrated in Figure The routed access design model has several advantages compared to the multitier classical STP-based access-distribution design model, including the following: Simpler and easier to troubleshoot, you can use a standard routing troubleshooting techniques, and you will have fewer protocols to manage and troubleshoot across the network Eliminate the reliance on STP and FHRP and rely on the equal-cost multipath EMCP of the used routing protocol to utilize all the available uplinks, which can increase the overall network performance Minimize convergence time during a link or node failure Note The routed access design model does not support spanning Layer 2 VLANs across multiple access switches, and this might not be a good choice for some networks.

Although expanding Layer 2 over routed infrastructure is achievable using other different overlay technologies, this might add complexity to the design, or the required features may not be supported with the existing platforms for the access or distribution layer switches.

Switch clustering: If the primary data center were to go offline for a certain period of time, this would affect all the other stores higher risk and could cost the business a larger loss in terms of money tangible and reputation intangible.

Therefore, the resiliency of the data center network is of greater consideration for this retailer than the resiliency of remote sites [17]. Similarly, the location of the outage sometimes influences the level of criticality and design consideration. Using the same example, an outage at one of the small stores in a remote area might not be as critical as an outage in one of the large stores in a large city [11].

In other words, BC considerations based on risk assessment and its impact on the business can be considered one of the primary drivers for many businesses to adapt network technologies and design principles to meet their desired goals [5]. Elasticity to Support the Strategic Business Trends Elasticity refers to the level of flexibility a certain design can provide in response to business changes.

A change here refers to the direction the business is heading, which can take different forms. For example, this change may be a typical organic business growth, a decline in business, a merger, or an acquisition. For instance, if an enterprise campus has three buildings and is interconnected directly, as illustrated in Figure , any organic growth in this network that requires the addition of a new building to this network will introduce a lot of complexity in terms cabling, control plane, and manageability.

These complexities result from the inflexible design, which makes the design incapable of responding to the businesss natural growth demand. Figure Inflexible Design To enhance the level of flexibility of this design, you can add a core module to optimize the overall design modularity to support business expansion requirements.

As a result, adding or removing any module or building to this network will not affect other modules, and does not even require any change to the other modules, as illustrated in Figure In other words, the design must be flexible enough to support the business requirements and strategic goals.

If network designers understand business trends and directions in this area, such understanding may influence, to a large extent, deign choices. Figure Flexible Design Similarly, a flexible network design must support the capability to integrate with other networks for examples, when mergers and acquisitions occur.

With mergers and acquisitions, however, the network can typically grow significantly in size within a short period of time, and the biggest challenge, in both scenarios mergers and acquisitions , is that network designers have to deal with different design principles, the possibility of overlapping IP address space, different control plane protocols, different approaches, and so on. IT as a Business Innovation Enabler In todays market, many businesses understand how IT technologies enhance their services and provide innovation to their customers.

Therefore, when a certain technology can serve as a business enabler that can help the organization to compete in the market or increase its customers satisfaction, the adoption of that technology will be supported by the business [17].

For example, nowadays, cloud-based data centers are opening new opportunities for hosting service providers to generate more revenue for the business. To offer good cloud-based services, there must be a reliable, flexible, and high-performance data center infrastructure to deliver this service.

Consequently, this engenders the initiative and will drive the business to build a high-performance, next-generation data center network. This network, by acting as a basis for cloud services, will be the enabler of the businesss revenuegeneration solution. The Nature of the Business Classifying the industry in which the business belongs or identifying the businesss origins can aid in the understanding of some indirect requirements, even if these are not mentioned explicitly.

For example, information security is almost always a must for a banking business whenever traffic crosses any external link. So by default, when planning a design for a business based in the banking industry, the design must support or offer security capabilities to gain acceptance from the business. In addition, industry-specific standards apply to IT infrastructure and services need to be considered. For instance, healthcare organizations may consider complying with the IEC standard.

These business priorities can influence the planning and design of IT network infrastructure. Therefore, network designers must be aware of these business priorities to align them with the design priorities.

This ensures the success of the network they are designing by delivering business value. For example, company Xs highest priority is to provide a more collaborative and interactive business communication, followed by the provision of mobile access for the users.

In this example, providing a collaborative and interactive communication must be satisfied first before providing or extending the communication over any mobility solution for the end users. In sum, it is important to align the design with the business priorities, which are key to achieving business success and transforming IT into a business enabler.

Functional requirements compose the foundation of any system design because they define system and technology functions. Specifically, functional requirements identify what these technologies or systems will deliver to the business from a technological point of view. For example, a Multiprotocol Label Switching MPLS -enabled service provider might explicitly specify a functional requirement in a statement like this: The provider edge routers must send VoIP traffic over 10G fiber link while data traffic is to be sent over the OC link.

Therefore, the functional requirements are sometimes referred to asbehavioral requirements because they address what a system does.

Note The design that does not address the businesss functional requirements is considered a poor design; however, in realworld design, not all the functional requirements are provided to the designer directly. Sometimes they can be decided on indirectly, based on other factors.

See the Application Requirements section later in this chapter for more details. Technical Requirements The technical requirements of a network can be understood as the technical aspects that a network infrastructure must provide in terms of security, availability, and integration. These requirements are often called nonfunctional requirements.

Technical requirements vary, and they must be used to justify a technology selection. In addition, technical requirements are considered the most dynamic type of requirements compared to other requirements such business requirements because, based on technology changes, they change often.

Technical requirements include the following: Heightened levels of network availability for example, using First Hop Redundancy Protocol [FHRP] Support the integration with network tools and services for example, NetFlow Collector, or authentication and authorization system RADIUS servers Cater for network infrastructure security techniques for example, control plane protection mechanisms or infrastructure access control lists [iACLs] Note The technical requirements help network designers to specify the required technical specifications features and protocols and software version that supports these specifications and sometimes influence the hardware platform selection based on its technical characteristics.

Application Requirements From a business point of view, user experience is one of the primary, if not the highest, priority that any IT and network design must satisfy. The term end users can be understood differently according to the type of business. The following are the most common categories of end users: Customers: Customer can be individuals, such as a customer of a bank, or they can be a collective, such as the customers of an MPLS service provider.

From a business point of view, customer satisfaction can directly impact the businesss reputation and revenue. Internal users: In this category, the targeted users are internal users. Productivity of these users can translate to business performance efficiency, which has a direct relation to business success and revenue.

Business partners: Partners represent those entities or organizations that work together to achieve certain goals. Therefore, efficient interaction between partners can enhance their business success in the service of strategic goal achievement.

Therefore, a network or a technology that cannot deliver the desired level of the users expectation also known as quality of experience means a failure to achieve either one of the primary business goals or failure to satisfy a primary influencer of business success. Consequently, networks and IT technologies will be seen by the business as a cost center rather than as a business enabler.

On this basis, networks design must take into account how to deliver the desired level of experience. In fact, what influences users experience is what they see and use. In other words, from a users perspective, the quality of experience with regard to applications and services used by different types of users is a key deterministic factor. Deploying network applications or services without considering the characteristics and network requirements of these applications will probably lead to a failure in meeting business goals.

For example, a company providing modern financial services wants to distinguish itself from other competitors by enabling video communication with its customer service call center agents. If the network team did not properly consider video communication requirements as a network application, the application will probably fail to deliver the desired experience for the end users customers in this example.

Consequently, this will lead to a failure in achieving the companys primary business goal. In other words, if any given application is not delivered with the desired quality of experience to the end users, the network can simply be considered as not doing its job.

Furthermore, in some situations, application requirements can drive functional requirements. For instance, if a service provider has a service level agreement SLA with its clients to deliver Voice over IP VoIP traffic with less than ms of one-way delay and less than 1 percent of packet loss, here VoIP requirements act as application requirements, which will drive the functional requirements of the PE devices to use a technology that can deliver the SLA.

In addition, network designers should also consider the answers to the following fundamental questions when evaluating application requirements: How much network traffic does the application require?

What is the level of criticality of this application and the service level requirement to the business? Does the application have any separation requirements to meet industry regulations and corporate security policies?

What are the characteristics of the application? How long does the application need after losing connectivity to reset its state or session? Design Constraints Constraints are factors or decisions already in place and cannot be changed and often lead to a direct or indirect impact on the overall design and its functional requirements.

In reality, various design constraints affect network design. The following are the most common constraints that network designers must consider: Cost: Cost is one of the most common limiting factors when producing any design; however, for the purpose of the CCDE practical exam, cost should be considered as a design constraint only if it is mentioned in the scenario as a factor to be considered or a tiebreaker between two analogous solutions.

Therefore, each phase can provide reverse feeding, as well, to the previous phase or phases to overcome issues and limitations that appear during the project lifecycle.

As a result, this will provide an added flexibility to IT in general and the design process in particular to provide a workable design that can transform the IT network infrastructure to be a business enabler.

Use this information to make design choices and decisions Plan. Generate, propose, or suggest a suitable design Design. Apply the selected design for example, an implementation plan Implement. Collect feedback or monitor Operate for optimization and enhancement Optimize. This understanding can also help those who have the opportunity to practice it in their work environment.

If they are working on a design and architecture project, they will have a tangible practical feeling and understand how the different stages of the design process can be approached and handled. How This Book Is Organized Although this book could be read cover to cover, it is designed to be flexible and allow you to easily move between chapters and sections of chapters to cover just the topics that you need more work with. This book is organized into six distinct sections.

Part I of the book explains briefly the various design approaches, requirements, and principles, and how they complement each other to achieve a true business-driven design. Chapter 1, Network Design Requirements: Analysis and Design Principles This chapter covers how the different requirements business, functional, and application can influence design decisions and technology selection to achieve a business-driven design.

This chapter also examines, when applicable, the foundational design principles that network designers need to consider. Part II of this book focuses on the enterprise networks, specifically modern converged networks. The chapter covers the various design options, considerations, and design implications with regard to the business and other design requirements.

Chapter 2, Enterprise Layer 2 and Layer 3 Design This chapter covers different design options and considerations related to Layer 2 and Layer 3 control plane protocols and advanced routing concepts. Chapter 3, Enterprise Campus Architecture Design This chapter covers the design options applicable to modern campus networks.

The chapter also covers some of the design options and considerations with regard to network virtualization across the campus network. Chapter 4, Enterprise Edge Architecture Design This chapter covers various design options and considerations with regard to the two primary enterprise edge blocks WAN edge and Internet edge.

Part III of the book focuses on service provider-grade networks. It covers the various design architectures, technologies, and control protocols, along with the drivers toward adopting the different technologies technical and nontechnical. Chapter 5, Service Provider Network Architecture Design This chapter covers the various architectural elements that collectively comprise a service provider-grade network at different layers topological and protocols layers.

The chapter also covers the implications of some technical design decisions on the business. The chapter also examines different design options and approaches to optimize Layer 3 control plane design scalability for service provider-grade networks.

Chapter 7, Multi-AS Service Provider Network Design This chapter focuses on the design options and considerations when interconnecting different networks or routing domains. The chapter examines each design option and then compares them based on various design aspects such as security and scalability. Part IV of the book focuses on data center networks design for both traditional and modern virtualized and cloud based data center networks.

This part also covers how to achieve business continuity goals. Chapter 8, Data Center Networks Design This chapter covers various design architectures, concepts, techniques, and protocols that pertain to traditional and modern data center networks. In addition, this chapter analyzes and compares the different design options and considerations, and examines the associated implications of interconnecting dispersed data center networks and how these different technologies and design techniques can facilitate achieving different levels of business continuity.

Part V of this book focuses on the design principles and aspects to achieve the desired levels of operational uptime and resiliency by the business. Chapter 9, Network High-Availability Design This chapter covers the different variables and factors that either solely or collectively influence the overall targeted operational uptime.

This chapter also examines the various elements that influence achieving the desired degree of network resiliency and fast convergence. Part VI of the book focuses on network technologies and services that are not core components of the CCDE practical exam. Chapter 10, Design of Other Network Technologies and Services This chapter briefly explains some design considerations with regard to the following network technologies and services, with a focus on certain design aspects and principles and without going into deep technical detail or explanation: IPv6, multicast, QoS, security, and network management.

Final Words This book is an excellent self-study resource to learn how to think like a network designer following a business-driven approach. You will learn how to analyze and compare different design options, principles, and protocols based on various design requirements. However, the technical knowledge forms only the foundation to pass the CCDE practical exam.

You also want to have a real feeling for gathering business requirements, analyzing the collected information, identifying the gaps, and producing a proposed design or design optimization based on that information.

If you believe that any topic in this book is not covered in enough detail, I encourage you to expand your study scope on that topic by using the recommended readings in this book and by using the recommended CCDE study resources available online atLearning Cisco. Network Design Requirements: Analysis and Design Principles Designing large-scale networks to meet todays dynamic business and IT needs and trends is a complex assignment, whether it is an enterprise or service provider type of network.

This is especially true when the network was designed for technologies and requirements relevant years ago and the business decides to adopt new IT technologies to facilitate the achievement of its goals but the businesss existing network was not designed to address these new technologies requirements. Therefore, to achieve the desired goal of a given design, the network designer must adopt an approach that tackles the design in a structured manner. There are two common approaches to analyze and design networks: The top-down approach: The top-down design approach simplifies the design process by splitting the design tasks to make it more focused on the design scope and performed in a more controlled manner, which can ultimately help network designers to view network design solutions from a business-driven approach.

The bottom-up approach: In contrast, the bottom-up approach focuses on selecting network technologies and design models first. This can impose a high potential for design failures, because the network will not meet the business or applications requirements. To achieve a successful strategic design, there must be additional emphasis on a business driven approach.

This implies a primary focus on business goals and technical objectives, in addition to existing and future services and applications. In fact, in todays networks, business requirements are driving IT and network initiatives as shown in Figure [6].

This ultimately will help these organizations to gain more competitive advantages, optimize their operational uptime, and reduce operational expenses fewer number of incidents as a result of the reduced number of information security breaches. Define application requirements from the upper layers of the Open Systems Interconnection OSI reference model that can help to identify the characteristics of an application.

Specify the design of the infrastructure along with the functional requirements of its components, for the network to become a business enabler. Monitor and gather additional information that may help to optimize and influence the logical or physical design to adapt with any new application or requirements. Design Scope It is important in any design project that network designers carefully analyze and evaluate the scope of the design before starting to gather information and plan network design.

Therefore, it is critical to determine whether the design task is for a green field new network or for a current production network if the network already exists, the design tasks can vary such as optimization, expansion, integration with other external networks, and so on. It is also vital to determine whether the design spans a single network module or multiple modules.

In other words, the predetermination of the design scope can influence the type of information required to be gathered, in addition to the time to produce the design. Table shows an example of how identifying the design scope can help network designers determine the areas and functions a certain design must emphasize and address. As a result, the scope of the information to be obtained will more be focused on these areas.

Related titles

For example, the candidate might have a large network to deal with, whereas the actual design focus is only on adding and integrating a new data center. Therefore, the candidate needs to focus on that part only.

However, the design still needs to consider the network as a whole, a holistic approach, when you add, remove, or change anything across the network as discussed in more detail later in this chapter.

Business Requirements This section covers the primary aspects that pertain to the business drivers, needs, and directions that individually or collectively can influence design decisions either directly or indirectly. The best place to start understanding the businesss needs and requirements is by looking at the big picture of a company or business and understanding its goals, vision, and future directions.

This can significantly help to steer the design to be more business driven. However, there can be various business drivers and requirements based on the business type and many other variables. As outlined inFigure , with a top-down design approach, it is almost always the requirements and drivers at higher layers such as business and application requirements that drive and set the requirements and directions for the lower layers.

Therefore, network designers aiming to achieve a business-driven design must consider this when planning and producing a new network design or when evaluating and optimizing an existing one.

The following sections discuss some of the business requirements and drivers at the higher layers and how each can influence design decisions at the lower layers.

Figure Business-Driven Technology Solutions Business Continuity Business continuity BC refers to the ability to continue business activities business as usual following an outage, which might result from a system outage or a natural disaster like a fire that damages a data center.

Therefore, businesses need a mechanism or approach to build and improve the level of resiliency to react and recover from unplanned outages. The level of resiliency is not necessarily required to be the same across the entire network, however, because the drivers of BC for the different parts of the network can vary based on different levels of impact on the business.

These business drivers may include compliance with regulations or the level of criticality to the business in case of any system or site connectivity outage.For instance, if an enterprise campus has three buildings and is interconnected directly, as illustrated in Figure , any organic growth in this network that requires the addition of a new building to this network will introduce a lot of complexity in terms cabling, control plane, and manageability.

This book covers a broad number of technologies, protocols and design options and considerations that can bring these aspects together and show how they can be used and thought about based on different requirements and business goals. This vision is primarily based on the concept that understanding what is supposed to happen at each stage is vital for a company or architect, designer to properly use the lifecycle approach and to get the most benefit from it. Integrate and analyze information from multiple sources for example, from e-mails or from diagrams to provide the correct answer for any given question.

This book covers a broad number of technologies, protocols and design options and considerations that can bring these aspects together and show how they can be used and thought about based on different requirements and business goals.

Considerations with regard to this use case include the following: Is the growth planned or organic? Whether you are preparing for the CCDE exam or simply wish to gain better insight into the art of network design in a variety of environments, this book helps you learn how to think like an expert network designer as well as analyze and compare the different design options, principles, and protocols based on different design requirements. In addition, the challenges associated with the design optimization of an existing network design to offer a higher level of scalability are important issues in this domain.

Therefore, the functional requirements are sometimes referred to asbehavioral requirements because they address what a system does. As outlined inFigure , with a top-down design approach, it is almost always the requirements and drivers at higher layers such as business and application requirements that drive and set the requirements and directions for the lower layers.