ASR920 và sản lượng giảm - đáng ngạc nhiên, IPTV dường như hoạt động tốt


7

Có lẽ câu hỏi của tôi sẽ hơi bất thường vì tôi sẽ không hỏi tại sao thứ gì đó không hoạt động. Thay vào đó, tôi sẽ hỏi tại sao mọi thứ dường như hoạt động tốt.

Tôi có ASR-920-24SZ-IM được kết nối với ASR9ks ngược dòng với các liên kết 2x10G. Thiết bị xuôi dòng là cisco 4948E hoạt động như một thiết bị truy cập (được kết nối qua một liên kết 10G khác). Các dịch vụ đã đưa ra 4948E là truy cập Internet, một loạt các E-LINE và IPTV.

Đường lên được sử dụng vừa phải - ~ 20% và 10%. Tuy nhiên, tôi quan sát đầu ra giảm trên giao diện về phía 4948E.

 Last clearing of "show interface" counters 01:52:25
 Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 122398
 Queueing strategy: fifo

Vì không có cấu hình QoS trên giao diện ASR920 đối với 4948E, nên có sẵn bộ đệm 120kB trên cổng đó. Nếu toán học của tôi là chính xác, điều này có nghĩa là ASR920 có thể lưu lượng truy cập có giá trị ~ 0,1 ms trong khi bùng nổ tốc độ dòng đến từ các liên kết 10G ngược dòng.

Điều thú vị là, khách hàng IPTV cũng như hệ thống giám sát không báo cáo bất kỳ vấn đề nào với lưu lượng phát đa hướng, vốn nhạy cảm với việc giảm gói. Mỗi kênh IPTV là luồng 10-20 Mbps (tốc độ bit thay đổi hoặc không đổi) với kích thước gói 1358 byte.

Làm thế nào có thể là multicast dường như không bị ảnh hưởng mặc dù sản lượng giảm?

BIÊN TẬP:

Sau 48 giờ quầy như dưới đây:

Last clearing of "show interface" counters 2d05h
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 1217201
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 576849000 bits/sec, 243662 packets/sec
30 second output rate 3706610000 bits/sec, 374245 packets/sec
 29523227831 packets input, 8591353468212 bytes, 0 no buffer
 Received 44508 broadcasts (0 IP multicasts)
 0 runts, 0 giants, 0 throttles 
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
 0 watchdog, 977069 multicast, 0 pause input
 50286674450 packets output, 62508590137876 bytes, 0 underruns

Thật không may, tôi không biết nó là gì, nhưng tôi sẽ cố gắng tìm hiểu.

Luồng kiểm tra là bitrate không đổi và khoảng cách giữa các gói là 500 chúng tôi.

Timestamp: 0.523377 Diff: 0.000544 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.523866 Diff: 0.000489 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.524424 Diff: 0.000558 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.524935 Diff: 0.000511 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.525474 Diff: 0.000539 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.525977 Diff: 0.000503 Sender: 10.200.200.207:34620 Size:1316

Hiện tại chỉ có một lời giải thích xuất hiện trong đầu tôi: các vụ nổ ngắn hơn 500 chúng tôi. Tôi biết rằng đầu ra giảm ở đó và phải mất> 100 chúng tôi để thả đuôi. Nếu các vụ nổ dài 200-300 chúng tôi sẽ gây ra sụt giảm đầu ra, nhưng sẽ không ảnh hưởng đến phát đa hướng.

Dưới đây tôi cung cấp một số đầu ra theo yêu cầu.

ASR920#show interfaces te0/0/27 stats
TenGigabitEthernet0/0/27
      Switching path    Pkts In   Chars In   Pkts Out  Chars Out
           Processor          0          0      22354    8324046
         Route cache          0          0          0          0
   Distributed cache          0          0          0          0
               Total          0          0      22354    8324046

Lệnh sh interfaces te0/0/27 switchdường như không được hỗ trợ trên nền tảng này.


1
Bạn đang sử dụng codec nào? h.264 SVC bằng cơ hội nào?
sergeyrar

1
Đầu ra lệnh cho thấy các gói ~ 122k đã bị hủy trong khoảng 2 giờ. Đó có thể không thực sự là nhiều. Có bao nhiêu gói được truyền trong cùng khoảng thời gian?
Marc 'netztier' Luethi

4
217201/50286674450 = 24E-6 hoặc 24 trong số 1.000.000 gói. Tôi nghi ngờ bạn sẽ không nhận ra điều đó.
Ron Trunk

Tuần tới tôi sẽ thực hiện các thử nghiệm bổ sung với luồng "nặng" hơn và tôi sẽ xem liệu các giọt có ảnh hưởng gì không. Tuy nhiên, tôi chắc chắn rằng điều này đòi hỏi một chút điều chỉnh.
mkurek

Phiên bản mã nào bạn đang sử dụng?
YLearn

Câu trả lời:


4

Như đã chỉ ra trong các ý kiến ​​trong khi số lượng thả có vẻ cao, khi so sánh với tổng lưu lượng truy cập thì nó thực sự khá thấp. Tốc độ giảm đầu ra là 2,4e-5 hoặc 0,0024%, do đó, nếu các giọt xảy ra đều đặn, luồng thử nghiệm của bạn sẽ gặp phải một gói bị mất khoảng 41,7k gói được gửi. Ngay cả phát đa hướng cũng không gặp khó khăn gì trong việc phục hồi từ mức giảm thấp và người dùng cuối có thể sẽ không nhận thấy bất cứ điều gì để phàn nàn. Điều đó cũng giả sử bất kỳ hoặc tất cả các giọt là đa hướng.

Bạn dường như cũng đang cố gắng để hiểu làm thế nào / tại sao các giọt xảy ra và đang xem các vụ nổ như là một nguồn của các giọt. Có bất kỳ lý do bạn tin rằng đây là trường hợp? Bạn chưa cung cấp phiên bản mã hoặc cấu hình từ ASR, nhưng tôi sẽ nghiêng nhiều hơn về một thứ như lỗi như CSCuw45886 là nguồn gốc của các vấn đề của bạn.


Cảm ơn vì đã trả lời. Hiện tại tôi đang chạy 15,5 (3) S4. Tôi nghĩ rằng lỗi bạn đề cập nên được sửa trong bản phát hành này. Tôi nghi ngờ sự sụt giảm có thể là do lưu lượng truy cập bùng nổ vì chúng tôi có nhiều khách hàng dân cư ở đó và kích thước bộ đệm mặc định trên nền tảng đó là tương đối nhỏ. Sau 5 ngày tỷ lệ giảm sản lượng là 0,04%. Tại sao bạn cho rằng giọt xảy ra đều đặn?
mkurek

@mkurek, vâng, nó nên được sửa (trừ khi nó vô tình được giới thiệu lại), nhưng có thể có các lỗi khác. Tôi không đưa ra giả định nào về vấn đề của bạn, nhưng bạn chưa cung cấp bất kỳ thông tin nào về bản chất của giọt, cho dù chúng xảy ra thường xuyên hay theo đợt. Tuy nhiên, việc tăng từ ~ 30 - 35% (các liên kết được báo cáo của bạn cộng với%) của liên kết 10G đang được sử dụng để bùng nổ hơn 100% chỉ trong vài giây mỗi lần có vẻ hơi căng. Có lẽ nếu bạn đã đẩy 60% trở lên ....
YLearn

1
Đối với các giọt xảy ra liên tục / tại các khoảng thời gian / phụ thuộc vào thời gian trong ngày ... Bạn có tình cờ có một hệ thống NMS chạy SNMP thu thập và đồ thị giảm số lượng (hoặc đếm từng giọt trong một khoảng thời gian bỏ phiếu nhất định )? Biểu đồ có thể giúp tiết lộ nếu sự xuất hiện của giọt thực sự là không đổi, liên quan đến giờ hành chính (nghĩa là hoạt động của người dùng có liên quan, có thể không đa hướng) hoặc nếu nó liên quan đến các mẫu khác (tức là lưu lượng phát đa hướng trên ngưỡng nhất định).
Marc 'netztier' Luethi

-2

Tỷ lệ rơi quá thấp đến mức có thể bỏ qua

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.