思科网络设计指南：实用方法，迈向CCIE专家

5星 · 超过95%的资源需积分: 10 61 浏览量更新于2024-07-20 2 收藏 8.19MB PDF 举报

《网络设计烹饪书：构建Cisco网络的实用指南》是由经验丰富的CCIE认证专家Michel Thomatis撰写的一本专业书籍。这本书旨在为网络工程师和顾问提供一个结构化的网络设计流程，帮助他们在遵循行业最佳实践的同时，实现关键的技术目标。尽管书中主要聚焦于Cisco设备，但作者强调了设计过程的通用性，允许读者将其他厂商的产品融入设计之中。该书的核心内容包括但不限于以下几个方面： 1. **设计流程**：书中详述了一种实用的设计方法论，它涵盖了从规划阶段到实施的完整流程，包括LAN（局域网）、WAN（广域网）、数据中心、互联网边缘、防火墙以及协作等多方面的设计步骤。设计师可以按照书中的指导，逐步构建出满足需求的网络架构。 2. **实用性与工具**：《网络设计烹饪书》提供了丰富的资源和工具，帮助读者解决实际设计问题。通过详细的示例和案例分析，读者能学习如何选择合适的网络拓扑、服务配置，以及如何优化性能和安全性。 3. **重要性与后果**：书中不仅传授设计技巧，还强调了设计网络的重要性，提醒读者设计不当可能带来的风险和问题。一个好的网络设计不仅要有稳定性，还要具备可扩展性、冗余性和安全性，以应对未来的业务需求变化。 4. **版权信息**：《网络设计烹饪书》享有完全的版权保护，未经作者书面许可，不得任何形式复制或使用。书中提及的CCDE、CCIE、CCDP等都是Cisco的认证标志，体现了作者的专业背景和认可。 5. **关于作者**：作者Michel Thomatis是资深的CCIE认证专家，他的专业经验和深厚知识为读者提供了权威的指导。他的作品反映了RouteHub Group LLC的专业精神，公司网址www.RouteHub.net。《网络设计烹饪书》是一本极具价值的参考书籍，无论是对初入行业的网络新手，还是希望提升设计技能的职业人士，都能从中收获实用的设计策略和实践经验，为职业生涯的成功奠定坚实基础。

Network Design Cookbook | The Archecture of Network Design

firewalls. This includes their limited experience with SonicWALL products. They never deployed them and have no

production experience. They are comfortable with how to administrator the Juniper because they know what to

expect. They also love Juniper support. They didn't like Cisco support because the whole SMARTnet contract

process and how to open a ticket was confusing to them. In reality they only done it twice and didn't know the

process.

Let's pick on me for a little bit. I prefer CLI, I can provide value-add expertise and implement many solutions via CLI

faster than GUI. However, GUI for Cisco UCM and Wireless LAN Controllers is very simple for administration. My

working experience with Juniper and Checkpoint firewalls is very limited and I am very comfortable with how to

administrator Cisco products.

Having a dislike besides the limited experience could be related to a bad relationship with the hardware vendor. For

example, I have a partner who was trying to become a Cisco partner and the process was confusing to them, which

took several months. The Juniper Partnership program was easier for them and that was the moment when they

preferred Juniper products over Cisco products. Therefore, they experienced a poor vendor relationship with Cisco

because of the partnership ordeal. ROUTEHUB GROUP became a Cisco partner in short time because again we

have experience and know how the process works.

Another reason for a dislike is when an IT person says Juniper Firewalls are faster than Cisco firewalls. I often like to

inquiry more on what they did to determine that. Such as what was the Cisco product model, the Juniper product,

who configured the Cisco Firewall, and who configured the Juniper Firewall. The answer most of the time is the

same. They configured both firewalls, but have higher experience with one product over the other. So in this case

they have strong experience with the Juniper products and little with Cisco. They did some Google searches to get

the Cisco firewall working. Also they used a Cisco product that was aimed for the SMB/Medium market and the

Juniper product chosen was aimed for Large enterprises.

So, it wasn't a fair alignment of products based on the business size and the configuration of the Cisco firewall was

questionable due to limited experience. This is fairly common when preferences and dislikes are exchanged.

The bottom line is this, no product is truly poor in performance and what it provides if it is deployed correctly. And if it

is deployed for the correct market segment and meets the requirements. That is the only factors that are important. I

have seen SonicWALL firewalls deployed in SMB networks causing no issues. I have seen Watchguard firewalls

deployed without any impact or issues. I have personally deployed Cisco Firewalls for Small to Large Enterprise

environments without any performance issues. The reason for these three cases is that they were all deployed

based on true production experience and met the overall requirements.

Therefore, when you choose the hardware for a component determine the following:

 Meets the business and technical requirements

 Aligns (if applicable) with the Business size of the network & business

 Simplicity and Administration

 Experience and the Support Model

 Realistic Metric Conditions (e.g. Performance)

Let me quickly discuss what "Realistic Metric Conditions" means. Different firewall models provide metrics such as

firewall throughput and VPN throughput. This also goes for switches with the forwarding rate, backplane traffic, to

throughput with a line module for a chassis. The main determination is to understand the realistic metrics. For

example, let's say that firewall product "A" provides 1Gbps for firewall performance and firewall product "B" provides

500Mbps for firewall performance. Most IT people will say that firewall product "A" is the better choice, especially if

that is their preference. Well if your Internet connection is a T1, then your highest possible throughput through the

firewall is roughly 1.5Mbps. That is far below the metrics for products "A" and "B", so both are a good choice.

This discussion can be heated as you can see, therefore, the only main point is choosing a hardware product based

on the requirements, support model, and value-add expertise for deploying the product into the network.

Network Design Cookbook | The Archecture of Network Design

3.1.3.3 UNIQUE ELEMENTS

A unique element is a network solution that is unique to the client/company. It is not seen in any recommendation or

case study design. Some unique elements can be justified by the requirements and building that solution ideally.

But some unique elements can be bad and likely created to serve a specific purpose.

Many network engineers who go into an existing network environment will look at the network and will often say "who

designed and configured this network?"

The irony is that every network has a unique element. And everyone has taken part of a unique element design at

some point in their career.

Let me provide an example to illustrate this point. I had a client who wanted to know if we can enable about 100+

DHCP scopes on the Cisco Core switch. Well yeah, it can, but it's not recommended, and it should be configured on

a dedicated DHCP server. Well this was the client’s network and they made the decision of using the Core switch to

act as the DHCP server with over a 100 DHCP scopes. Then they can follow-up with using a dedicated DHCP server

sometime in the future. Something that is often said and quickly forgotten about until an issue comes up.

This is an example of a unique element that can occur in one form or another. So, why is this the case?

It's several things, but they are usually done for the following reasons:

 Support Band-Aid

 Cost

 Convenience and Availability

 Simplicity

 Unique Requirement

With the example I provided, it was a matter of simplicity, convenience, and availability. Because ideally a dedicated

server should be taking care of those functions. But that requires a new server to be built, with likely new hardware

that needs to be purchased, hence, additional cost. Next, they have to install the OS, spend time configuring it, and

then enable DHCP. Next they have to rack the server, cable, power, and then test it out. It's a lot easier to enable

DHCP services on the Core switch to eliminate doing any of those steps. That is how it happens and it all starts from

the decision maker.

Here is another example, let's say there is a server running DHCP scopes, but it fails and is impacting the business.

As a quick Band-Aid they enable DHCP services on a Cisco router and everything is running again. The services

may eventually get moved back to a server, but will likely remain on the Core router for an extended period of time.

Even up to a point when the next network engineer/consultant who comes in will say “who designed and configured

this network? Why is DHCP enabled on a Core router with all these scopes? They should be deployed on dedicated

server”.

You get the point and see how the cycle works.

This is considered as a preferences that may determine how a network is designed.

Network Design Cookbook | The Archecture of Network Design

3.2.2 TECHNICAL OBJECTIVES

The following objectives are considered within our design as technical requirements:

1. PERFORMANCE: Performance deals with the rate and quality of traffic delivery across a network.

Bandwidth and throughput are one of the components that can describe performance. QoS is another

component that assigns priority to specific traffic on the network. Port buffers and queues also fall into

quality of traffic delivery which is often discussed with Congestion Management and Avoidance with QoS.

2. RELIABILITY: Reliability deals with the redundancy and stability of the network. Faults on a network will

occur in the form of hardware, software, or human related failures. Therefore, it’s important to understand

how long can the network be down (the SLA) before a serious impact occurs (e.g. customers leaving). The

answer for most cases would be as minimal as possible, less than 1 or 4 hours. Therefore building a

network with redundancy is important to consider and construct within a network design. However, higher

redundancy requirements mean higher costs and complexity.

3. SCALABILITY: Scalability deals with the growth or increase of users, servers, and services on the network.

Building a network to accommodate today’s requirements is not good if we don’t understand the

requirements and expectations for tomorrow. This is obtained during the requirements gathering.

4. SECURITY: Security provides protection of confidentiality and integrity for users, servers, and services on

the network. This may include mandates or regulatory compliances such as PCI, HIPPA, or SOX. Much of

best practices focus around this technical objective.

5. FLEXIBILITY: Flexibility has a dual meaning and purpose. The first deals with understanding the potential

use of network services and technologies that may be included with the design in the future. For example,

maybe the design today does not include VoIP, but it may be included in another 1 or 2 years. Therefore,

the design should consider those additions. The second deals with integration of existing or legacy

infrastructure. This may include an older phone system or PBX with requirements to ideally work with the

new design like a new Cisco Unified Communication Solution. Understanding these considerations and

possible additions is also important.

6. NETWORK MANAGEMENT: Network Management also has a dual purpose dealing with Management and

Monitoring. Monitoring deals with providing proactive fault management (e.g. monitoring when devices are

UP or DOWN, traffic usage), performance management (e.g. using a protocol called Netflow to view traffic

flow conversations and top-talkers), and configuration management (e.g. backing up configuration,

performing audits and defining best practices). Management deals with the IT support model of who will be

supporting the designed network at a Tier 1, Tier2, and maybe a Tier 3 level. Deploying a complex design

with Tier 1 level staff may present challenges, so understanding the support model is important.

Network Design Cookbook | The Archecture of Network Design

3.2.3 SOLUTIONS

There are a lot of networking terms that are out there and it's confusing to know where they belong such as Routing,

Switching, LAN, Wireless, Security, VPN, Unified Communication, and the list goes on. I have come up with an

organized way to group these technologies and solutions. They are broken down into Network Services and Network

Solutions.

A Network Solution would be one of the following:

 LAN, Data Center, WAN, Internet Edge, Remote Access, Cloud Computing

And Network Services would be one of the following:

 Routing & Switching, Security & VPN, Multicast, QoS, IPv6

What are the differences between the two? Consider the solution as a completed puzzle with multiple pieces. Some

solutions may have more pieces than others. Each piece in the puzzle (our solution) is a Network Technology or

service. For example, a WAN Solution will likely to consist of services like Routing, Security, and VPN. Business

Owners or IT Management will tend to seek out solutions and do not need to know about the details, which are the

network services. Network Engineers and Consultants will likely seek out Network services within a solution for

assistance.

3.2.4 LOCATIONS

Locations deals with where the components on the network reside. The location can be any of the following:

 IDF

 MDF

 Data Center

 Office/Other

The IDF is a wiring closet that connects back to an MDF room or Data Center.

The MDF is a wiring closet that connects to other IDF rooms including Data Centers.

The Data Center is a dedicated room with Data Center components such as racks, cabinets, ladder racks, cooling,

and more. Mainly used for server farm environments.

Office/Other locations is where a user's computer/laptop is located such as an office, cubicle, or a work space. It's ea

location that has 1 or 2 ports that is wired back to an IDF, MDF, or maybe a Data Center location.

There can be variations for some of these rooms such as a Lab or training class. A training classroom can be a type

of "Office/Other" location. Or a lab can exist in either a Data Center, IDF, or an MDF room.

It's based on how the wiring is constructed.

Therefore, it's important to understand all of the computer room locations and how everything is wired.

This is information gathered during the requirements phase that makes a difference in defining what the design will

eventually look like.

剩余437页未读，继续阅读

zfhu2001

粉丝: 1
资源: 33

思科网络设计指南：实用方法，迈向CCIE专家

Network Design

Neural Network Design, 2nd Edition

kali-linux-network-scanning-cookbook-zh-kali

Python-Network-Programming-Cookbook-training

Kali Linux Network Scanning Cookbook - Second Edition [2017]

Python-Network-Programming-Cookbook-Second-Edition:Python网络编程手册–第二版，由Packt发行

kali-linux-network-scanning-cookbook-2nd.pdf【高清文字版】【带书签】

cookbook-monasca-notification:Chef Cookbook - Monasca 通知引擎

cookbook-monasca-schema:Chef Cookbook - Monasca 数据库架构

cookbook-monasca-thresh:Chef Cookbook - Monasca 阈值引擎

最新资源