lớp mặc định phù hợp với kiểm soát lưu lượng?

Tôi đang thấy một vấn đề với BFD trên một liên kết đang được kiểm soát chính xác, nơi nó xuất hiện trong thời gian mà các gói BFD được tối đa hóa không được chuyển sang phía bên kia. Tôi đang tự hỏi nếu BFD hellos là đối tượng của máy đánh bóng hoặc nếu họ rơi ra ngoài máy đánh bóng. Nếu họ phải tuân theo một chính sách thì có đơn giản như việc thêm một trận đấu cho DSCP CS6 và ưu tiên cho nó không? Dưới đây là cấu hình:

interface GigabitEthernet1/1
 service-policy output 500meg
end

Router-1#sh policy-map 500meg
  Policy Map 500meg
    Class class-default
     police cir 500000000 bc 31250000 be 31250000
       conform-action transmit
       exceed-action drop
       violate-action drop

@Mud, bạn đã có khá nhiều câu trả lời cho câu hỏi của bạn trải rộng trên một số ý kiến ​​vì vậy tôi chỉ hợp nhất nó ở đây trong một câu trả lời duy nhất.

Trên 7600s / 6500, bạn có thể lọc BFD (lưu lượng trên mặt phẳng điều khiển) ở cấp giao diện giống như bất kỳ lưu lượng nào khác (lưu lượng quá cảnh đi qua thiết bị).

Khi bạn áp dụng ACL cho một cổng trên thẻ dòng, nó sẽ được áp dụng cho tất cả lưu lượng truy cập trên giao diện đó. Lưu lượng truy cập cần được xử lý bởi RSP hoặc DFC nếu bạn đang sử dụng chúng cần được xử lý ở đó sau khi ACL được xử lý.

Theo nguyên tắc thông thường, tôi đã bao gồm lưu lượng trên mặt phẳng điều khiển trong các chính sách QoS muộn, chẳng hạn như sau đây trong đó "lớp NC" chỉ khớp với CS6 & CS7:

policy-map QoS-Example
 class NC
  bandwidth percent 2
 !
 class REALTIME
  police rate percent 10
   conform-action transmit
   exceed-action drop
  !
  priority level 1
 !
 class 1
  bandwidth percent 22
 !
 class 2
  bandwidth percent 24
 !
 class 3
  bandwidth percent 12
 ....... and so on

Nếu bạn viết chính sách CoPP cho 7600s / 6500 của mình, bạn cần viết ACL phù hợp với tất cả các loại lưu lượng máy bay điều khiển có liên quan của bạn. Vì vậy, bạn cũng có thể khớp lưu lượng BFD bằng cách khớp lưu lượng đến / từ cổng UDP 3784 (và khóa nó xuống IP giao diện của bạn nếu có thể).

Như @ytti nói rằng bạn cần cảnh giác với bộ định thời BFD trong thiết lập của mình, nếu bạn chưa có DFC thì BFD đang chạy của bạn trên nguồn RSP / CPU. Trong trường hợp đó, bạn cũng có thể muốn xem xét điều chỉnh lệnh toàn cầu "quy trình tối đa thời gian" và lịch trình quy trình "trình lập lịch phân bổ xxx xxx".

Tối thiểu được khuyến nghị của Cisco là bfd interval 100 min_rx 100 multiplier 3nhưng trên một số hộp sản xuất không có DFC tôi thực sự đang chạy bfd interval 500 min_rx 500 multiplier 3rất ổn, tôi nghĩ trên các hộp có DFC mà tôi không có quyền truy cập ngay bây giờ tôi đang chạy tương tự.

Bạn có thể xem các tài liệu tham khảo này để biết thêm thông tin, bao gồm điều chỉnh BFD và ACL cho lưu lượng mặt phẳng điều khiển (cả CoPP và ACL giao diện), và một số điều chỉnh trên mặt phẳng điều khiển thường là thông lệ tốt, cũng là hành vi QoS với lưu lượng trên mặt phẳng điều khiển:

http://www.cisco.com/c/en/us/td/docs/routers/7600/troubledhoot/guide/7600_Trouble_Sh Boot.pdf

http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-2SR/configuration/guide/swcg/dos.html

http://www.cisco.com/web/about/security/intellect/coppwp_gs.html

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-manloyment-queueing/18664-rtgupdates.html

Do tính chất quan trọng của gói điều khiển BFD, nó không đi qua bản đồ chính sách QoS đi ra trên đường ra và được đặt trực tiếp trong hàng đợi đi ra. Khẳng định với TAC.

Theo tài liệu cisco này, "Người dùng không thể, ví dụ, lọc hoặc áp dụng Chất lượng dịch vụ (QoS) cho gói BFD được truyền". Vì vậy, tôi cho rằng các gói đó có cờ PAK_PRIORITY .