By now, you know how networks shoul

By now, you know how networks should work. Like other complex systems, however, they
don’t always work as planned. Many things can go wrong on a network, just as many things
can go wrong with your car, your house, or a project at work. In fact, a network professional
probably spends more time fixing network problems than designing or upgrading a network.
Some breakdowns (such as an overtaxed processor) come with plenty of warning, but others
(such as a hard disk controller failure) can strike instantly.
The best defense against problems is prevention. Just as you maintain your car regularly, you
should monitor the health of your network regularly. Of course, even the most well-monitored
A customer called the managed security services firm I worked for and asked why
one of his subnets was unable to reach the HTTP proxy service that was running on
the inside interface of the Linux-based firewall we managed for him. I dutifully fired
up tcpdump, an open source network diagnostic utility, and watched packets arriving
from the subnet in question. The packets didn’t look obviously malformed, and they
were also correctly addressed for the proxy service on the firewall. Usually this sort of
customer call resulted from a poorly configured automatic proxy configuration file,
but not this time.
Puzzled, I watched as the customer removed the proxy address specification on a
workstation in the affected network and was suddenly able to reach the world. This
suggested that the problem was somehow related to the firewall. In each case,
though, I would see the packets arrive on the inside interface of the firewall.
If the firewall were dropping the packets, I would have seen it in the logging. So I
watched the socket state with netstat and saw that the proxy service never received
the connection initiation segments (TCP SYN) from the problem subnet. Though I
could see the packets arriving, the IP stack seemed to be ignoring them.
After examining the packet traces at various layers using tcpdump and Wireshark,
I asked for another pair of eyes to help me. He noticed something I had overlooked.
The 10th byte of the Ethernet frame destination address on the frame bound for the
proxy service was wrong. This was the smoking gun. It meant that when packets
passed through their switch to the Internet as a whole, the frame destination address
was not mangled. But when packets passed through to the inside interface on the
firewall, the switch was corrupting the frame destination address.
Our customer’s network equipment vendor confirmed that the problem was the
electronics on one of the switch ports. Sometimes another pair of eyes is all it takes.
Martin A. Brown
Renesys Corporation
On the Job
596 Chapter 13 Troubleshooting Network Problems
Copyright 2013 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
network will sometimes experience unexpected problems. For example, a utility company
could dig a new hole for its cable and accidentally cut your dedicated link to the Internet. In
such a situation, your network performance can go from perfect to disastrous in an instant. In
this chapter, you will learn how to diagnose and solve network problems in a logical, stepby-
step fashion, using a variety of tools.
Troubleshooting Methodology
Successful troubleshooters proceed logically and methodically. This section introduces a
basic troubleshooting methodology, leading you through a series of general problemsolving
steps.
Following are steps for troubleshooting network problems as recommended by CompTIA.
You should be familiar with these steps to demonstrate Network+ mastery:
● Identify the problem.
 Gather information.
 Identify symptoms.
 Question users.
 Determine if anything has changed.
● Establish a theory of probable cause.
 Question the obvious.
● Test the theory to determine cause.
 Once the theory is confirmed, determine the next steps to resolve the problem.
 If the theory is not confirmed, reestablish a new theory or escalate.
● Establish a plan of action to resolve the problem and identify potential effects.
● Implement the solution or escalate as necessary.
● Verify full system functionality and, if applicable, implement preventive measures.
● Document findings, actions, and outcomes.
Bear in mind that experience in your network environment may prompt you to follow
the steps in a different order or to skip certain steps entirely. For example, if you
know that one segment of your network is poorly cabled, you might try replacing a
section of cable in that area to solve a connectivity problem

Kết quả (Việt) 1:

By now, you know how networks should work. Like other complex systems, however, theydon’t always work as planned. Many things can go wrong on a network, just as many thingscan go wrong with your car, your house, or a project at work. In fact, a network professionalprobably spends more time fixing network problems than designing or upgrading a network.Some breakdowns (such as an overtaxed processor) come with plenty of warning, but others(such as a hard disk controller failure) can strike instantly.The best defense against problems is prevention. Just as you maintain your car regularly, youshould monitor the health of your network regularly. Of course, even the most well-monitoredA customer called the managed security services firm I worked for and asked whyone of his subnets was unable to reach the HTTP proxy service that was running onthe inside interface of the Linux-based firewall we managed for him. I dutifully firedup tcpdump, an open source network diagnostic utility, and watched packets arrivingfrom the subnet in question. The packets didn’t look obviously malformed, and theywere also correctly addressed for the proxy service on the firewall. Usually this sort ofcustomer call resulted from a poorly configured automatic proxy configuration file,but not this time.Puzzled, I watched as the customer removed the proxy address specification on aworkstation in the affected network and was suddenly able to reach the world. Thisý kiến cho rằng vấn đề bằng cách nào đó có liên quan đến tường lửa. Trong mỗi trường hợp,Tuy nhiên, tôi sẽ nhìn thấy các gói tin đến bên trong giao diện của các bức tường lửa.Nếu tường lửa đã thả các gói dữ liệu, tôi nào có thấy nó trong đăng nhập. Vì vậy tôitheo dõi các ổ cắm nhà nước với netstat và thấy rằng dịch vụ ủy quyền không bao giờ nhận đượcCác kết nối khởi đoạn (TCP SYN) từ vấn đề mạng con. Mặc dù tôicó thể thấy các gói dữ liệu đến, chồng IP có vẻ là bỏ qua chúng.Sau khi kiểm tra các dấu vết gói tại các lớp bằng cách sử dụng tcpdump và Wireshark,Tôi yêu cầu cho một cặp mắt giúp tôi. Ông đã nhận thấy một cái gì đó tôi đã bỏ qua.Byte Ethernet, 10 khung địa chỉ đích trên khung bị ràng buộc cho cácDịch vụ proxy đã sai. Đây là khẩu súng hút thuốc. Nó có nghĩa rằng khi gói dữ liệutrải qua chuyển đổi của Internet như một toàn thể, địa chỉ đích của khungkhông phải đọc sai. Nhưng khi gói dữ liệu thông qua thông qua các bên trong giao diện trên cáctường lửa, chuyển đổi corrupting địa chỉ đích của khung.Nhà cung cấp thiết bị mạng của khách hàng của chúng tôi xác nhận rằng vấn đề là cácthiết bị điện tử trên một trong các cổng chuyển đổi. Đôi khi, một đôi mắt là tất cả phải mất.Martin A. BrownCông ty cổ phần RenesysTrong công việc596 chương 13 gỡ rối vấn đề mạngCopyright 2013 Cengage học. Tất cả các quyền. Có thể không được sao chép, quét hoặc trùng lặp, toàn bộ hoặc một phần. Do quyền điện tử, một số nội dung bên thứ ba có thể được bị đàn áp từ eBook và/hoặc eChapter(s).Biên tập review đã coi là rằng bất kỳ nội dung bị đàn áp không vật chất ảnh hưởng đến tổng thể kinh nghiệm học tập. Cengage học có quyền loại bỏ nội dung bổ sung bất kỳ lúc nào nếu tiếp theo quyền hạn chế yêu cầu nó.mạng đôi khi sẽ gặp vấn đề bất ngờ. Ví dụ, một công ty tiện íchcó thể khai thác một lỗ hổng mới cáp của mình và vô tình cắt liên kết chuyên dụng của bạn với Internet. Ởtình hình như vậy, hiệu suất mạng của bạn có thể đi từ hoàn hảo tai hại ngay lập tức. Ởchương này, bạn sẽ tìm hiểu làm thế nào để chẩn đoán và giải quyết các vấn đề về mạng trong một Penguin, hợp lý -bước thời trang, bằng cách sử dụng một loạt các công cụ.Phương pháp xử lý sự cốTrình gỡ rối thành công tiến hành một cách hợp lý và phương pháp. Phần này giới thiệu mộtphương pháp xử lý sự cố cơ bản, dẫn bạn qua một loạt các chung problemsolvingCác bước.Sau đây là các bước để gỡ rối các vấn đề mạng theo khuyến cáo của CompTIA.Bạn nên quen thuộc với các bước sau để chứng minh mạng + làm chủ:● xác định vấn đề.Thu thập thông tin.Xác định các triệu chứng.Câu hỏi người dùng.Xác định nếu bất cứ điều gì đã thay đổi.● thiết lập một lý thuyết về nguyên nhân có thể xảy ra.Câu hỏi rõ ràng.● kiểm tra lý thuyết để xác định nguyên nhân gây ra.Khi lý thuyết xác nhận, xác định các bước tiếp theo để giải quyết vấn đề.Nếu lý thuyết không được xác nhận, hãy thiết lập lại một lý thuyết mới hoặc leo thang.● thiết lập một kế hoạch hành động để giải quyết vấn đề và xác định tác dụng.● triển khai các giải pháp hoặc leo thang khi cần thiết.● kiểm tra hệ thống đầy đủ chức năng, và nếu có thể, thực hiện các biện pháp phòng ngừa.● tài liệu phát hiện, hành động và kết quả.Ghi nhớ rằng các kinh nghiệm trong môi trường mạng của bạn có thể nhắc nhở bạn làm theoCác bước theo một thứ tự khác nhau hoặc để bỏ qua bước nhất định hoàn toàn. Ví dụ, nếu bạnbiết rằng một trong những phân đoạn của mạng lưới của bạn kém gửi, bạn có thể thử thay thế mộtphần cáp trong khu vực đó để giải quyết một vấn đề kết nối

Kết quả (Việt) 2:

Bởi bây giờ, bạn biết cách mạng phải làm việc. Cũng giống như các hệ thống phức tạp khác, tuy nhiên, họ
không luôn luôn làm việc theo kế hoạch. Nhiều thứ có thể đi sai trên một mạng, cũng giống như nhiều điều
có thể đi sai với chiếc xe của bạn, ngôi nhà của bạn, hoặc một dự án tại nơi làm việc. Trong thực tế, một chuyên viên mạng
có thể dành nhiều thời gian hơn các vấn đề sửa chữa mạng lưới hơn thiết kế hoặc nâng cấp một mạng.
Một số sự cố (chẳng hạn như một bộ xử lý overtaxed) đi kèm với rất nhiều cảnh báo, nhưng những người khác
(chẳng hạn như một đĩa thất bại điều khiển cứng) có thể tấn công ngay lập tức.
Bảo vệ tốt nhất chống lại vấn đề là phòng ngừa. Cũng như bạn duy trì xe của bạn thường xuyên, bạn
nên theo dõi sức khỏe của mạng của bạn thường xuyên. Tất nhiên, ngay cả những nổi theo dõi
Một khách hàng được gọi là các công ty dịch vụ an ninh quản lý tôi làm việc cho và hỏi lý do tại sao
một trong các mạng con của ông là không thể tiếp cận các dịch vụ HTTP proxy đó đã được chạy trên
giao diện bên trong của tường lửa dựa trên Linux, chúng tôi quản lý cho anh ấy. Tôi ngoan ngoãn bắn
lên tcpdump, một tiện ích chẩn đoán mạng mã nguồn mở, và theo dõi các gói tin đến
từ các subnet trong câu hỏi. Các gói không nhìn rõ ràng là bị thay đổi, và họ
cũng đã được giải quyết một cách chính xác cho các dịch vụ proxy trên các bức tường lửa. Thông thường loại này
gọi khách hàng kết quả từ một tập tin cấu hình proxy tự động cấu hình kém,
nhưng không phải lúc này.
Bối rối, tôi xem như là khách hàng loại bỏ các đặc điểm kỹ thuật địa chỉ proxy trên một
máy trạm trong mạng bị ảnh hưởng và đã bất ngờ có thể tiếp cận thế giới. Điều này
gợi ý rằng vấn đề đã được bằng cách nào đó liên quan đến tường lửa. Trong mỗi trường hợp,
mặc dù, tôi sẽ nhìn thấy các gói tin đến trên giao diện bên trong của tường lửa.
Nếu tường lửa được thả các gói tin, tôi đã thấy nó trong khai thác gỗ. Vì vậy, tôi
theo dõi tình trạng ổ cắm với netstat và thấy rằng các dịch vụ proxy không bao giờ nhận được
các phân đoạn kết nối khởi đầu (TCP SYN) từ các vấn đề mạng con. Mặc dù tôi
có thể thấy các gói đến, ngăn xếp IP dường như bị bỏ qua chúng.
Sau khi kiểm tra các dấu vết gói tin tại các lớp khác nhau sử dụng tcpdump và Wireshark,
tôi hỏi cho một đôi mắt để giúp tôi. Ông nhận thấy một cái gì đó tôi đã bỏ qua.
Các byte thứ 10 của địa chỉ đích khung Ethernet frame ràng buộc đối với các
dịch vụ proxy là sai. Đây là khẩu súng hút thuốc. Nó có nghĩa là khi các gói tin
đi qua chuyển đổi của họ vào Internet như một toàn thể, các địa chỉ đích khung
không đọc sai. Nhưng khi các gói dữ liệu qua giao diện bên trong trên
tường lửa, chuyển đổi là hư địa chỉ đích khung.
Nhà cung cấp thiết bị mạng lưới khách hàng của chúng tôi đã khẳng định rằng vấn đề là các
thiết bị điện tử vào một trong các cổng chuyển đổi. Đôi khi một đôi mắt là tất cả mất.
Martin A. Brown
Tổng công ty Renesys
On the Job
596 Chương 13 Vấn đề khắc phục sự cố mạng
Copyright 2013 Cengage Learning. Tất cả các quyền. Có thể không được sao chép, scan, hoặc trùng lặp, toàn bộ hoặc một phần. Do quyền điện tử, một số nội dung của bên thứ ba có thể bị ức chế từ sách điện tử và / hoặc eChapter (s).
Tổng biên tập đã coi rằng bất kỳ nội dung bí không vật chất ảnh hưởng đến học tập kinh nghiệm tổng thể. Cengage Learning có quyền loại bỏ nội dung bổ sung bất cứ lúc nào nếu hạn chế quyền tiếp theo yêu cầu nó.
Mạng đôi khi sẽ gặp phải vấn đề bất ngờ. Ví dụ, một công ty tiện ích
có thể khai thác một lỗ mới cho cáp của mình và vô tình cắt liên kết riêng của bạn với Internet. Trong
tình hình như vậy, hiệu suất mạng của bạn có thể đi từ hoàn hảo để tai hại ngay lập tức. Trong
chương này, bạn sẽ tìm hiểu làm thế nào để chẩn đoán và giải quyết vấn đề mạng trong một hợp lý, stepby-
thời trang bước, sử dụng một loạt các công cụ.
Troubleshooting Phương pháp
gỡ rối được thành công tiến hành một cách hợp lý và có phương pháp. Phần này giới thiệu một
phương pháp xử lý sự cố cơ bản, dẫn bạn thông qua một loạt các quyết vấn đề chung
bước.
Sau đây là các bước cho các vấn đề xử lý sự cố mạng theo khuyến cáo của CompTIA.
Bạn nên làm quen với các bước sau để chứng minh Network + chủ:
● Xác định các vấn đề.
? Thu thập thông tin.
? Xác định các triệu chứng.
? Người sử dụng câu hỏi.
? Xác định nếu bất cứ điều gì đã thay đổi.
● Thiết lập một lý thuyết về nguyên nhân có thể xảy ra.
? Câu hỏi rõ ràng.
● Kiểm tra lý thuyết để xác định nguyên nhân.
? Một khi lý thuyết này được xác nhận, xác định các bước tiếp theo để giải quyết vấn đề.
? Nếu lý thuyết chưa được xác nhận, tái lập một lý thuyết mới hoặc leo thang.
● Thiết lập kế hoạch hành động để giải quyết vấn đề và xác định các tác động tiềm năng.
● Thực hiện các giải pháp hay leo thang khi cần thiết.
● Kiểm tra xem hệ thống chức năng đầy đủ, và nếu áp dụng, thực hiện phòng ngừa biện pháp này.
phát hiện ● Tài liệu, hành động, và kết quả.
Ghi nhớ rằng kinh nghiệm trong môi trường mạng của bạn có thể nhắc bạn làm theo
các bước trong một thứ tự khác nhau hoặc để bỏ qua bước nhất định hoàn toàn. Ví dụ, nếu bạn
biết rằng một phân đoạn mạng của bạn vẫn chưa được dây, bạn có thể thử thay thế một
phần của cáp trong khu vực đó để giải quyết một vấn đề kết nối