Điều gì sẽ gây ra độ trễ cao bất cứ khi nào có lưu lượng truy cập trên mạng WAN?


16

Tôi có một mạng đã trải qua tốc độ internet chậm. Sau rất nhiều lần khắc phục sự cố, tôi đã xác định rằng mọi nội dung phát / tải xuống sẽ khiến độ trễ của lưu lượng mạng WAN phát nổ.

Ví dụ, không tải, tôi ping 8.8.8.8 trong khoảng 30ms. Nếu tôi bắt đầu truyền phát YouTube trên cùng một máy tính, độ trễ sẽ tăng lên khoảng 500ms, với phương sai khoảng 400ms. Nếu tôi tắt video, độ trễ trở lại 30ms. Nhưng, nếu tôi có một người dùng trên cùng một mạng LAN bắt đầu phát trực tuyến pandora, vấn đề sẽ trở lại.

Mạng của tôi bị tắt một chuyển đổi 10/100. Công tắc được kết nối trực tiếp với bộ định tuyến DSL. Tôi thường có kết nối 6Mb.

Trong khắc phục sự cố, tôi đã hoàn thành các bước sau:

  • Quét bằng wireshark từ một số máy trạm tìm kiếm các gói sai. (Tôi sẽ bao gồm nhưng quét có thông tin bí mật). Không có gì thậm chí từ xa ra khỏi bình thường.
  • Bộ định tuyến thay thế bằng một mô hình nâng cấp, sau đó nâng cấp firmware.
  • Có ISP tăng tốc độ được đo chính xác trên speedtest.net (10 xuống, 1,5 lên). Vấn đề là hoàn toàn giống nhau.
  • Có ISP trao đổi thẻ ở cuối của họ, chỉ trong trường hợp họ có phần cứng / cổng xấu.
  • Đã thử nghiệm tại một văn phòng khác với chính xác ISP / gói. Có nhiều máy tính phát trực tuyến YouTube @ 1080p và pandora mà không ảnh hưởng đến độ trễ.
  • Tắt mọi máy tính nhưng một và chạy vào ban đêm khi không có người dùng ở đó.
  • Giám sát lưu lượng LAN, không bao giờ gặp vấn đề về độ trễ.

Tôi biết rằng, nếu tôi đạt đến giới hạn băng thông hoặc tốc độ bị nghẽn ở một số phần cứng, nó sẽ gây ra vấn đề này. Tuy nhiên, có vẻ như không phải vậy. Hầu như bất kỳ lưu lượng truy cập qua mạng WAN sẽ tăng độ trễ. Vấn đề là như nhau ngay cả khi tôi tăng gần gấp đôi tốc độ kết nối. Khi tôi có hai người dùng trên pandora và một vài người lướt web, internet sẽ không có gì (các gói bị rơi, các trang sẽ không tải). Tôi có một nửa kết nối ở nhà và phát trực tuyến netflix / youtube / pandora đồng thời của chúng tôi thậm chí không chạm tới 5 Mb của tôi.

Câu hỏi: Điều gì sẽ gây ra độ trễ cao bất cứ khi nào lưu lượng truy cập đi qua mạng WAN?


1
câu hỏi này bao trùm một phạm vi rộng, điều bạn đang nói đến là xử lý sự cố mạng và tìm sự cố. Câu hỏi nên được cụ thể hơn. Btw này không có gì để làm với wireshark (như cách gắn thẻ của bạn mô tả). Điều đó nói rằng, chào mừng bạn đến với networkengineering;)
Bulki

Có câu trả lời nào giúp bạn không? nếu vậy, bạn nên chấp nhận câu trả lời để câu hỏi không xuất hiện mãi mãi, tìm kiếm câu trả lời. Ngoài ra, bạn có thể cung cấp và chấp nhận câu trả lời của riêng bạn.
Ron Maupin

Câu trả lời:


10

Điều này nghe có vẻ như là một dạng " đệmbloat ", có lẽ là một phần của DSLAM / LNS đang thực hiện giới hạn tốc độ 6Mb.

Nó có thể là hộp CPE của bạn, nhưng điều đó ít có khả năng.


+1 Nó có thể là một số giới hạn tốc độ được định cấu hình hoặc định hình trên phần ISP, nhưng nó cũng có thể là một CPE chất lượng kém (hoặc trục trặc). Tôi đã thấy các CPE được đánh giá ở tốc độ 40Mb / giây bắt đầu lật đổ ở tốc độ 10Mpbs vì họ không thể xử lý tốc độ pps cao chẳng hạn. Một tỷ lệ pps cao của các gói nhỏ thực sự làm căng chúng.
jwbensley

Ồ, tôi đã không thấy rằng anh ấy đã thay thế CPE. Tôi đã bỏ lỡ điểm đạn đó!
jwbensley

9

Tôi sẽ xác minh nơi độ trễ đang xảy ra. Sử dụng một công cụ như MTR để kiểm tra độ trễ tại mỗi bước nhảy. MTR kết hợp thống kê ping cho mỗi bước nhảy với một lộ trình theo dõi và rất có thể giúp thu hẹp loại vấn đề này.

Trên một hộp linux, lệnh sẽ mtr 8.8.8.8có một phiên bản windows của công cụ này.

Đầu ra sẽ cho bạn thấy độ trễ bắt đầu từ đâu. Nếu nó nằm trên mạng ISP, bạn có thể chuyển tiếp đầu ra tới ISP và giúp họ sử dụng nó để khắc phục sự cố mạng của họ.

Nếu độ trễ bắt đầu trong mạng của bạn, bạn cũng có thể thu hẹp vấn đề.


1
Có phiên bản mtr nào dành cho thiết bị Cisco IOS không? Tôi biết nó có thể được chạy từ Junos CLI
DrBru

5

Kiểm tra số liệu thống kê đường DSL. (xen kẽ so với fastpath, bộ đếm lỗi, v.v.)

Thử nghiệm tại một địa điểm khác đã thử nghiệm một dòng khác nhau , có thể trên DSLAM khác. Điều này cho thấy cơ sở hạ tầng ISP không đáng trách. Nó mạnh mẽ cho thấy đường DSL của bạn bị lỗi. Có thể chính DSLAM bị tắc nghẽn, nhưng rất khó để bạn có thể là người đẩy nó qua dòng dự đoán và lặp đi lặp lại.

Nếu các tế bào ATM đang bị hỏng (vận chuyển cho hầu hết DSL), bạn sẽ thấy sự chậm lại đáng kể như thế này vì toàn bộ khung phải được gửi lại.


3

Bất cứ khi nào tôi gặp trường hợp khách hàng gặp phải độ trễ mạng, điều đầu tiên cần làm là kiểm tra từng kết nối riêng lẻ trong mạng. Thông thường có một thiết bị trong đó xảy ra nút cổ chai.

Nếu mạng sử dụng thấp, tôi sẽ vô hiệu hóa hoàn toàn QoS trên mọi thứ trừ thiết bị được kết nối internet (vì QoS sẽ làm chậm lưu lượng trong môi trường chuyển mạch).

Trong gói chụp của bạn, tôi sẽ phân tích I / O và xem bạn có nhận được cao nguyên ở bất cứ đâu không. Điều này có thể chỉ ra lưu lượng truy cập lớn sẽ gây ra việc xếp hàng sẽ làm chậm việc phân phối các gói hoặc hoàn toàn thoát khỏi các gói.

Tôi cũng sẽ kiểm tra CPU của từng thiết bị khi bạn gặp sự cố. Nếu bạn thấy CPU nhảy lên thì đó có lẽ là thiết bị có vấn đề của bạn. Kiểm tra các bản ghi là tốt để xem nếu có bất kỳ lỗi.

Ngoài ra, tôi sẽ chắc chắn tất cả các kết nối đang đàm phán ở tốc độ tối đa (tốc độ 100 song công hoàn toàn).

Ngoài ra, hãy thử vô hiệu hóa bất kỳ tường lửa hoặc dịch vụ bảo mật.


2

Một thứ khác để xem xét sẽ là kết nối giữa công tắc của bạn và modem DSL. Các triệu chứng bạn đang mô tả gần như có vẻ như có sự không phù hợp song phương giữa hai người.

Một cách khác để loại trừ công tắc là loại bỏ hoàn toàn công tắc và kiểm tra kết nối với một máy được gắn trực tiếp vào modem DSL.


2

Độ trễ cao / thông lượng xấu khi lưu lượng truy cập cao đôi khi là dấu hiệu của sự cố L1 (không khớp song công / cáp xấu / sợi bẩn). Bạn đã kiểm tra rằng đây không phải là trường hợp?


0

Đây có thể là một nút cổ chai ngược dòng? Không chắc chắn bạn đang ở đâu trên thế giới, nhưng có lẽ ISP có băng thông quốc tế khủng khiếp. Speedtest.net sẽ mặc định cho máy chủ gần nhất.


0

Phương pháp đơn giản mà tôi đã sử dụng là hàm theo dõi tìm kiếm thời gian phản hồi cao trong các dấu vết và kiểm tra hệ thống đó có bị lỗi phần cứng, tấn công DOS, phân loại không đúng QoS hay không. tất nhiên bạn cần truy cập vào tất cả các thiết bị trong đường dẫn. Thật dễ dàng cho tôi trong thời gian đó kể từ khi tôi làm việc cho một viễn thông.


0

Hệ điều hành bạn đang thử nghiệm này là gì? Nếu là Windows, theo mặc định, có dịch vụ "Bộ lập lịch gói QoS" được cài đặt và liên kết với giao diện mạng. Nó sẽ khởi động tùy thuộc vào các cài đặt cơ bản của ngăn xếp mạng và chủ động trì hoãn mọi lưu lượng không được phân loại là "đa phương tiện".

Cố gắng xóa nó khỏi giao diện và kiểm tra lại kết quả của bạn.

Hoặc tốt hơn nữa, hãy cấu hình lại đúng cách: http://www.dslreports.com/faq/3688


0

Tôi sẽ thêm vào kinh nghiệm của mình rằng một số ISP xử lý gói ICMP với mức độ ưu tiên thấp nhất. Nó đã xảy ra một lần, mỗi khi tôi bắt đầu youtube thậm chí có "yêu cầu đã hết thời gian".

Đăng winmtr trước khi bắt đầu video và trong khi video đang phát. Bắt đầu truyền phát lần thứ 2 và hãy xem điều này sẽ ảnh hưởng đến cả gói ICMP và video thứ nhất như thế nào.


0

Nếu bạn đang kết nối qua một công tắc 10/100 và có chế độ tự động trên một phần của nó, bạn có thể có một sự không phù hợp song công. Điều này sẽ gây ra va chạm thường xuyên khi có tải trên mạng không hiển thị khi mọi thứ tương đối yên tĩnh. Các vụ va chạm sẽ gây ra sự thay đổi theo ý muốn khi buộc các liên lạc phải lùi lại và có thể gây ra sự chậm lại dường như vô lý.


0

Xin lỗi để hồi sinh một chủ đề cũ. OP đã viết:

... Hầu như bất kỳ lưu lượng truy cập nào trên mạng WAN sẽ tăng độ trễ ...

Đây là những triệu chứng chính xác của Bufferbloat. Bộ định tuyến có khả năng xếp hàng quá nhiều lưu lượng và bỏ đói các luồng nhỏ (cần thiết để cung cấp khả năng đáp ứng.)

Bộ định tuyến của bạn cần một cách để giảm thiểu vấn đề "độ trễ khi tải". Bạn có thể vượt qua QoS, nhưng điều này đòi hỏi rất nhiều cấu hình và điều chỉnh liên tục.

Trạng thái của nghệ thuật đã phát triển kể từ OP, vì vậy hãy tìm kiếm Bufferbloat, AQM, CoDel, fq_codel, Cake, PIE hoặc các kỹ thuật khác.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.