Khắc phục sự cố mạng chậm chậm

Tất cả chúng ta đều có một khiếu nại rằng "mạng" bị "chậm" tại một số điểm: có thể bị cục bộ hóa thành một phòng (bộ chuyển mạch) hoặc một máy tính, có thể chỉ là Internet (DNS? Vấn đề về trình duyệt?), Có thể chỉ là một ứng dụng (truy vấn SQL chạy dài? Quét AV đang chạy?).

Khi bạn đã loại trừ các sự cố hệ thống và / hoặc ứng dụng rõ ràng, làm thế nào để bạn kiểm tra mạng về hành vi chậm chạp hoặc thất thường? Bạn có làm việc theo cách của bạn lên các lớp OSI? Nếu vậy, làm thế nào để kiểm tra từng lớp? Bạn làm gì để đảm bảo mạng vật lý vẫn ổn ở một môi trường không xác định? Điều gì về quá nhiều chương trình phát sóng hoặc một cơn bão phát sóng? Lớp 3 trở lên? theo dõi? Bất kỳ lời khuyên, phương pháp, ý tưởng khác? Phải có các tính năng và công cụ (phản chiếu cổng, SNMP, giám sát, v.v.) cho tất cả các kích cỡ của mạng?

tcpdump và wireshark là bạn của bạn.

Tôi thấy rằng việc xem các gói trên mạng của mạng 'chậm' so với mạng 'tốt' thường là điều xác định chính xác vấn đề.

Có nhiều loại 'chậm'.

Bạn có thể theo dõi độ trễ đến các trang web địa phương và internet bằng cách sử dụng một công cụ như SmokePing. (Có thể cấu hình SmokePing để theo dõi độ trễ ICMP cũng như độ trễ dịch vụ từ các dịch vụ TCP)

Thiết bị chuyển mạch của bạn nên theo dõi các gói phát sóng so với các gói unicast. Vẽ đồ thị tỷ lệ đó.

Tôi cũng thích theo dõi các dấu vết (kiểm tra tên miền của các bước nhảy ISP giữa các trang web 'quan trọng' của tôi).

Tôi hy vọng những ý kiến ​​này giúp.

Thật khó để đưa ra câu trả lời cụ thể vì 90% công việc này là kinh nghiệm dạy cho bạn biết nên tìm loại vấn đề nào và 90% còn lại là biết tìm Google trên đâu để có gợi ý về nơi bắt đầu.

Tôi thường thử các công cụ túi giấy như để khách hàng thể hiện vấn đề (chủ yếu là để loại trừ các vấn đề về ngón tay và bất kỳ vấn đề nào khách hàng có thể mô tả vấn đề của mình), sau đó cố gắng sao chép vấn đề trên một máy tính khác. Làm điều đó thường cung cấp cho bạn cái nhìn sâu sắc về nơi để tìm.

Đừng quên vấn đề khắc phục khởi động lại, đặc biệt là đối với các hệ thống Windows, ngay cả ngày nay. Nó đã từng như thế này đến mức tôi sẽ hỏi mọi người "Bạn đã khởi động lại chưa? Hãy thử điều đó và cho tôi biết nếu vấn đề vẫn còn" - điều này đã khắc phục một tỷ lệ rất lớn các vấn đề tôi được hỏi.

Thường xuyên có trái cây treo thấp trong các vấn đề về độ phân giải DNS và kết nối cơ bản (ACL trên bộ định tuyến, lỗ hổng không khí trong mạng, ping / traceroutes / mtrs đến các trang web từ xa, v.v.).

Đối với các dịch vụ bạn có quyền kiểm soát trực tiếp, chạy nagios hoặc thứ gì đó để đảm bảo dịch vụ thực sự đang chạy có thể thường xuyên kích hoạt bạn khắc phục sự cố trước khi khách hàng nói với bạn về chúng. Bạn cũng có thể muốn được thu thập số liệu thống kê, trực tiếp thông qua munin hoặc một cái gì đó, hoặc thông qua SNMP đến một cái gì đó như Cacti.

Tôi thường cố gắng để Cacti chạy với ít nhất tất cả các công tắc và tường lửa cốt lõi của mình; khi có thể, tôi chạy Cacti chống lại mọi thứ tôi có thể. Trong những trường hợp này, tôi thường tìm kiếm những thứ như số lỗi cổng hoặc lưu lượng truy cập quá mức. Biểu đồ tường lửa từ một số thiết bị có thể cho bạn thấy việc sử dụng CPU và các phiên đồng thời; bạn sẽ học được ở ngưỡng nào thiết bị tường lửa của bạn bắt đầu có vấn đề.

Tường lửa của bạn có thể đăng nhập vào thiết bị nhật ký hệ thống; nếu vậy, hãy đăng nhập mọi thứ bạn có thể và xem qua những gợi ý. Điều này sẽ dễ dàng hơn nếu bạn chạy một cái gì đó như syslog-ng hoặc rsyslog hoặc splunk cho phép bạn phân chia nhật ký của mình một chút thay vì xử lý một tệp nguyên khối.

Tôi cũng cố gắng chạy nfsen với ít nhất là bên trong tường lửa của tôi và đường lên tới nhà cung cấp internet nếu có thể. Điều này cho phép bạn quay ngược thời gian để xem xét các phiên để xem ai đang làm gì; điều này đôi khi có thể bắt gặp những hành vi thú vị.

Dưới đây là một số công cụ hữu ích để khắc phục sự cố độ trễ và các sự cố mạng khác:

• các chế độ OSI l - bắt đầu từ phía dưới và làm việc theo cách của bạn lên
• ping - kiểm tra RTT của bạn (tức là độ trễ)
• HTTP ping - hữu ích nếu tường lửa của bạn chặn ICMP bình thường
• ping -r 9 - hữu ích để xác định các tình huống định tuyến không đối xứng
• theo dõi - các gói của tôi đến đó như thế nào và các bộ định tuyến trên đường đi đáp ứng như thế nào? Xin lưu ý rằng các bộ định tuyến thường xử lý các gói này ở mức ưu tiên thấp, vì vậy hiệu suất thực có thể tốt hơn.
• Wireshark - có một số chuyên môn, nhưng bạn không thể có cấp độ thấp hơn nhiều
• Bộ phân tích TCP / IP của SpeedGuide.net - kiểm tra cài đặt TCP của PC
• Trình tối ưu hóa SG TCP - (chỉ dành cho Windows) đề xuất các cách để tối ưu hóa cài đặt NIC của bạn
• IP Chicken - địa chỉ IP nguồn (không phải NAT) của bạn là gì?
• http://downForveryveryororjustme.com/ - có thể đó là bạn ...
• Kiểm tra tốc độ băng thông - kiểm tra tốc độ tải xuống / tải lên của bạn
• Công cụ mạng - chạy các công cụ / kiểm tra từ bên ngoài mạng của bạn
• kiểm tra các cổng mạng của bạn để biết lỗi / CRC's / etc. -
• kiểm tra mạng của bạn để sử dụng quá mức (màn hình băng thông) và bão phát
• kiểm tra lũ lụt unicast - sử dụng wireshark và giám sát lưu lượng unicast không dành cho máy trạm của bạn.
• xác minh cây cầu gốc cây bao trùm của bạn được đặt đúng cách

Nếu bạn đang chạy một mạng không dây, một trong những sự cố chậm thường xuyên là nhiễu kênh. Một loạt các SSID trong một khu vực thực sự có thể làm chậm lưu lượng mạng. (Hãy suy nghĩ: bản demo của iPhone 4 tại WWDC '10).

Khắc phục sự cố sự cố này khá dễ dàng nếu với phần mềm có thể hiển thị cho bạn các mẫu lưu lượng không dây trong khu vực. Có một trang web miễn phí và dựa trên web tốt tại: http://meraki.com/tools/stumbler . (tiết lộ: Tôi làm việc cho Meraki)

Để giảm nhiễu, tốt nhất là ở các kênh 1, 6 hoặc 11. Sử dụng thiết bị 802.11n với tần số 5GHz cũng có thể giúp ích.

Tôi luôn bắt đầu với việc theo dõi các công cụ lớp 2 bằng Cacti . Điều đó sẽ cung cấp cho bạn một lượng dữ liệu tốt mà bạn có thể sử dụng để tìm kiếm các mẫu và bạn có thể so sánh các biểu đồ Cacti của mình khi mọi thứ hoạt động tốt so với khi người dùng thấy chậm.

Có lẽ nó sẽ không tìm ra vấn đề chính xác nhưng nó sẽ cho bạn một điểm khởi đầu tốt để giúp thu hẹp vấn đề.

Tôi bắt đầu ở bộ định tuyến ngoài cùng và tìm đường xuống và tôi đo hiệu suất theo cách nguyên thủy nhất: sử dụng trang web kiểm tra băng thông hoặc trang FTP bên ngoài đã biết sẽ cung cấp cho bạn tốc độ tải lên / tải xuống và tiếp tục giảm cho đến khi bạn tìm mức độ mà vấn đề cư trú

Một khi bạn biết vấn đề ở đâu, hãy triển khai các công cụ và màn hình ưa thích của bạn. Nhưng đừng lãng phí thời gian để làm những thứ đó trên mỗi lớp. Nó sẽ mất mãi mãi.

Bạn cũng cần biết máy chủ và môi trường máy tính để bàn / máy khách của mình, thay vì chỉ đơn giản là giả sử người dùng đúng khi họ nói "mạng chậm". Bạn cần khắc phục một cách có phương pháp từng vấn đề - như những người khác đã nói, trước tiên bạn có thể xem và tái tạo lý tưởng lỗi, sau đó làm việc từ đó theo cách hợp lý cho kịch bản.

Tuy nhiên, việc quản lý và giám sát tốt trên mạng và máy chủ có thể giúp bạn tiết kiệm rất nhiều thời gian, bởi vì bạn không cố gắng đưa ra thiết bị khi đang di chuyển trong khi cũng có thể cố gắng giảm thiểu hoặc khắc phục các triệu chứng và xử lý người dùng phàn nàn / khách hàng.

Câu trả lời cho tcpdump và wireshark không sai, đó có thể là những phần quan trọng trong bộ công cụ của bạn. Nhưng trừ khi bạn chắc chắn rằng đó thực sự là mạng, họ không nên là điều đầu tiên bạn tiếp cận.

Mạng chậm là một hiện tượng phổ biến. Tốc độ mạng chậm có thể được gây ra bởi một số điều. để khắc phục sự cố mạng chậm là một trong những công việc phổ biến và rắc rối nhất trong quản lý mạng hàng ngày.

Theo phân tích, lý do chính cho mạng chậm là:

Loopback
Broadcast/Multicast storm
Virus attack
Server slow response
Too many clients
Application slow response
Error client mask

Làm thế nào chúng ta có thể nhanh chóng tìm ra nguyên nhân cho mạng chậm xảy ra? Đó là một ý tưởng tốt để chụp và phân tích các gói với một bộ phân tích mạng (Ax3soft Unicorn, wireshark, v.v.).

Bạn cũng đọc bài viết "Tìm lý do cho mạng chậm", nhấp vào URL ( http://www.ids-sax2.com//Unicorn/Tutorials/Find-R Reason-for-Slow-Network-with-Ax3soft-Unicorn .htm ) đến thăm nó.