Tại sao các LSP chi phí bằng nhau của tôi không tải cân bằng như nhau khi sử dụng băng thông tự động?


7

Đầu tiên, tôi thêm câu hỏi này và tự trả lời vì loại hành vi này hoàn toàn không tìm thấy ở đâu, hy vọng nó sẽ giúp được ai đó.

Vấn đề:

Chúng tôi sử dụng băng thông tự động để xử lý các đăng ký băng thông cho các LSP của chúng tôi. Các LSP có chi phí bằng nhau và xuất hiện trong các bảng chuyển tiếp / định tuyến của chúng tôi một cách thích hợp như các bước nhảy tiếp theo có sẵn cho mỗi điểm đến.

Tuy nhiên, đối với một điểm đến duy nhất, 4 LSP chi phí bằng nhau không tải cân bằng như nhau (hoặc thậm chí gần bằng nhau). Chúng tôi hiểu rằng JUNOS sử dụng thuật toán cân bằng tải trên mỗi luồng mặc dù tuyên bố "mỗi gói" trong chính sách để cho phép cân bằng tải. Nhưng điều đó không giải thích được sự khác biệt lớn giữa mỗi đăng ký cho LSP (sự mất cân bằng đăng ký này xảy ra nhiều lần mỗi ngày, đó không phải là một lần xảy ra), như vậy:

jhead@R1> show route protocol rsvp 1.1.1.1 detail

1.1.1.1/32 (2 entries, 1 announced)
        State: <FlashAll>
        *RSVP   Preference: 7/1
                Next hop: 192.168.1.1 via xe-0/0/0.0 weight 0x1 balance 35%, selected
                Label-switched-path LSP1
                Next hop: 192.168.1.2 via xe-1/0/0.0 weight 0x1 balance 35%
                Label-switched-path LSP2
                Next hop: 192.168.1.3 via xe-0/0/1.0 weight 0x1 balance 26%
                Label-switched-path LSP3
                Next hop: 192.168.1.4 via xe-0/0/0.0 weight 0x1 balance 5%
                Label-switched-path LSP4

R1-R4 là MX480 và CORE-R1-R4 là MX960.

Dưới đây là các biểu đồ so sánh đăng ký RSVP và việc sử dụng LSP. Màu đỏ là thuê bao, màu xanh là sử dụng. Bạn có thể thấy rằng việc sử dụng sau khi đặt phòng gần như chính xác trong suốt cả ngày. Chúng ta sẽ thấy các mục đăng ký rất gần nhau giữa các LSP hướng đến cùng một đích.

nhập mô tả hình ảnh ở đây nhập mô tả hình ảnh ở đây nhập mô tả hình ảnh ở đây nhập mô tả hình ảnh ở đây

Cấu trúc liên kết:

R1 - R4 là các bộ định tuyến xâm nhập cho tất cả các LSP, chúng có 2 hoặc 4 LSP đối với mỗi bộ định tuyến lõi.

nhập mô tả hình ảnh ở đây

Cấu hình:

Cấu hình LSP là một điểm đến duy nhất từ ​​R1, giống như một ví dụ. Tất cả các LSP được cấu hình chính xác theo cùng một cách (một lần nữa, với 2 hoặc 4).

[edit protocols mpls]
    statistics {
        file mpls-stats;
        interval 300;
        auto-bandwidth;
    }
    traffic-engineering bgp;
    label-switched-path LSP1 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }
    label-switched-path LSP2 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }
    label-switched-path LSP3 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }
    label-switched-path LSP4 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }

[edit protocols rsvp]
load-balance bandwidth
interface xe-0/0/0.0 {
    bandwidth 9g;
}
interface xe-0/0/1.0 {
    bandwidth 9g;
}
interface xe-1/0/0.0 {
    bandwidth 9g;
}

[edit routing-options forwarding-table]
export load-balance;

Tôi sẽ tự trả lời điều này vào lúc nào đó hôm nay hoặc ngày mai, nhưng nếu bất cứ ai muốn thực hiện một cú đâm - hãy thoải mái.
Jordan Head

Câu trả lời:


9

Vấn đề là:

[edit protocols rsvp]
load-balance bandwidth

Nếu bạn xem tài liệu của Juniper về các LSP RSVP Cân bằng tải chi phí không đồng đều , thì nó ghi:

Để cân bằng tải không đồng đều sử dụng băng thông để hoạt động, bạn phải có ít nhất hai LSP chi phí bằng nhau cho cùng một bộ định tuyến đầu ra và ít nhất một trong các LSP phải có giá trị băng thông được định cấu hình tại [chỉnh sửa giao thức mpls đường dẫn chuyển nhãn tên đường dẫn] mức phân cấp. Nếu không có LSP nào được cấu hình băng thông, cân bằng tải phân phối bằng nhau được thực hiện. Nếu chỉ một số LSP có cấu hình băng thông, các LSP không có bất kỳ băng thông nào được cấu hình sẽ không nhận được bất kỳ lưu lượng nào.

Điều này ngụ ý rằng bất kể tính năng đó được cấu hình là gì, sẽ không xảy ra cân bằng tải chi phí bằng nhau nếu bạn không đặt tĩnh một giá trị băng thông trên một LSP riêng lẻ, như vậy:

[edit protocols mpls label-switched-path LSP1]
bandwidth 2g

Tuy nhiên, băng thông tự động trên thực tế được tính là thiết lập giá trị băng thông, mặc dù nó không có trong cấu hình.

Khi băng thông tự động được bật, RPD sẽ bắt đầu theo dõi mức tiêu thụ băng thông. Nó sẽ chỉ định các giá trị băng thông dựa trên việc sử dụng và sau đó, câu lệnh "băng thông cân bằng tải" trong RSVP sẽ ngay lập tức bắt đầu cố gắng giữ tỷ lệ lưu lượng trong các đăng ký đó (lần lượt là 35, 35, 26, 5). Vấn đề với điều này là nó không bao giờ cho băng thông tự động cơ hội điều chỉnh đồng đều, vì mục tiêu của "băng thông cân bằng tải" là giữ cho lưu lượng càng gần các tỷ lệ đó càng tốt. Điều này có ý nghĩa khi chúng được thiết lập một cái gì đó như, 10, 30, 20, 40.

Đây thực chất là một điều kiện chạy đua giữa "băng thông cân bằng tải" và "băng thông tự động"

Sau khi xóa:

[chỉnh sửa giao thức rsvp] băng thông cân bằng tải

Lưu lượng điều chỉnh (với một tiếng nấc nhẹ, xem bên dưới):

LƯU Ý: Đây là một ví dụ từ một bộ định tuyến khác bị ảnh hưởng bởi cùng một vấn đề.

jhead@R1> show log mpls-stats

LSP1 (LSP ID 3388, Tunnel ID 2646)    177150801 pkt   155450491134 Byte 178572 pps 152286259 Bps Util 228.46% Reserved Bw 66660264 Bps
LSP2 (LSP ID 3393, Tunnel ID 2647)            0 pkt              0 Byte      0 pps        0 Bps Util  0.00% Reserved Bw 116698880 Bps

Vì bạn loại bỏ khả năng cân bằng tải (đối với RSVP), PFE sẽ lập trình lại thành một đường duy nhất cho đến khi điều chỉnh băng thông tự động xảy ra tự động hoặc bạn có thể buộc điều chỉnh:

request mpls lsp adjust-autobandwidth

Và bên dưới, băng thông điều chỉnh cho 2 LSP có cùng triệu chứng, cấu hình thay đổi và điều chỉnh xảy ra vào giữa ngày thứ sáu, bạn có thể thấy sự khác biệt trong đăng ký gần như ngay lập tức.

nhập mô tả hình ảnh ở đây nhập mô tả hình ảnh ở đây


0

"Chúng tôi hiểu rằng JUNOS sử dụng thuật toán cân bằng tải trên mỗi luồng mặc dù tuyên bố" mỗi gói "trong chính sách để cho phép cân bằng tải"

Tìm thấy tuyên bố đó là khá đúng khi sử dụng iperf để thử nghiệm một số tình huống cân bằng tải. Với một phiên iperf duy nhất, lưu lượng truy cập hoàn toàn không cân bằng, nhưng khi kích hoạt các phiên iperf tương đương, lưu lượng sẽ được cân bằng tải.

Mặc dù tài liệu Juniper đề nghị khác! http://www.juniper.net/documentation/en_US/junos13.2/topics/usage-guferences/mpls-configuring-load-balANCE-across-rsvp-lsps.html

Tôi tự hỏi nếu điều trên được áp dụng như từ JUNOS13.2


Trừ khi bạn có thiết bị Juniper cực kỳ cũ trong mạng của mình, tất cả các cân bằng tải được băm trên mỗi FLOW (mặc dù có ghi từng gói trong chính sách). Vì vậy, tùy thuộc vào cách bạn thiết lập các thử nghiệm của mình, hành vi mà bạn thấy sẽ được mong đợi - một luồng duy nhất, từ một phiên iperf duy nhất sẽ không được trải rộng trên các liên kết (hoặc LSP). Tuy nhiên nếu bạn thêm một luồng thứ hai, nó sẽ. Cấu hình "cân bằng tải rsvp", HOÀN TOÀN khác nhau, vì nó làm thay đổi cân bằng tải thông thường. Tôi không chắc bạn đang gặp vấn đề gì, nhưng, bạn nên hỏi nó trong một câu hỏi để có câu trả lời tốt hơn, ý kiến ​​không phải là vấn đề.
Jordan Head
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.