BGP đa đường với các ASN khác nhau có khả thi cho các mạng sản xuất?

trên Cisco (lệnh này bị ẩn vì một số lý do)

#bgp bestpath as-path multipath-relax

Hành vi BGP mặc định chỉ cài đặt các tuyến đường có chính xác cùng AS_PATH vào RIB. Với đa thư giãn, AS_PATH chỉ cần có cùng độ dài.

Những vấn đề nó có thể gây ra? Tại sao không được sử dụng thường xuyên hơn?

Là nhà cung cấp dịch vụ vận chuyển, tính năng này có làm phức tạp việc khắc phục sự cố không (tôi đang nghĩ về khiếu nại của người dùng cuối về hiệu suất mạng)? Có làm cho khó khăn hơn để biết lưu lượng truy cập cụ thể đường dẫn tại một thời điểm nhất định? Có cái gì khác để có thể hỗ trợ khắc phục sự cố. Tôi không chắc về khả năng mở rộng và chi phí cho NetFlow trong mạng SP.

bgp bestpath as-path multipath-relaxđược giới thiệu bởi CSCea19918. Thông thường cân bằng tải eBGP yêu cầu các tuyến ứng cử viên phải là đường dẫn chi phí bằng nhau; tức là các thuộc tính BGP giống hệt nhau:

• cùng trọng lượng
• cùng địa phương-Pref
• cùng đường dẫn AS (cả số AS và độ dài đường dẫn AS)
• cùng nguồn gốc
• cùng MED
• hop tiếp theo khác nhau

Như bạn đã đề cập, lệnh này làm giảm yêu cầu AS-Path tương tự, vì vậy mọi ứng cử viên eBGP AS-Path có cùng độ dài đường dẫn AS có thể được sử dụng để cân bằng tải eBGP (điều này sẽ không cân bằng tải giữa các đường dẫn eBGP và iBGP). Nếu bạn chạy BGP giữa nhiều ISP và bạn đang tìm kiếm sự cân bằng tải ra tốt hơn giữa các kết nối ngược dòng của mình, điều này có thể giúp bạn thoát ra.

Những vấn đề nó có thể gây ra?

Không có nhiều nguy hiểm miễn là bạn là khách hàng doanh nghiệp không cung cấp dịch vụ vận chuyển cho ASN khác; đối với nhà cung cấp dịch vụ vận chuyển, nó có thể hoàn toàn an toàn, nhưng tôi không thể chắc chắn rằng không có vòng lặp định tuyến nếu ASN quá cảnh sử dụng tính năng này . Lúc đầu, tôi nghĩ sẽ dễ dàng có một vòng lặp trong các trường hợp ASN quá cảnh, khi phản ánh nhiều hơn tôi không thể tìm thấy một vấn đề thực sự.

Tại sao nó sẽ hiếm khi được sử dụng?

Câu hỏi hay, nó đã xuất hiện từ ít nhất năm 2005.

The   basic  issue   is   that  the   BGP   speaker  configured   with
"multipath-relax"   gets  into   a  control   plane  <->   data  plane
inconsistency; i.e.  it advertises  only the  best path,  but installs
multiple paths in the forwarding  that have different ASPATHs than the
best. This breaks the basic tool BGP has to detect loops - ASPATH loop
check.

A (distorted) scenario below. I am sure you can come up with
a better example with a bit more time at hand.

            ...............
            : R4  AS1 (10/8)
           /:..............
     ..../......
     :  R5 AS2
     :....\.....
       /   \  ...............
     /      --:--R1
  R6 AS4      :    \    AS3
     \--------:--- R2
              :    /
              : R3 (10/8)
              :..............

In this example,
- R3 in AS3 and R4 in AS1 announce a prefix 10/8. R5 in AS2 receives
  the prefix from R1(AS3) and R4(AS1).
- AS2 is configured with 'multipath-relax' and chooses both paths
  for multipath forwarding, though it selects AS1's path as best.
- R5 advertises the prefix with AS_PATH "2 1" to R6, and R6 in turn
   to R2.
- Because of some specific policy, it is possible that R2(AS3)
  chooses R6's path as best. If it happens, there is a loop.
  Note that R1-R2-R3 represents the physical connectivity of
  the routers in AS3.