MPLS L3VPN và BGP “Allow-AS-In”

[Cẩm Thanh]

MPLS L3VPN và BGP “Allow-AS-In”: Khi nào bạn cần cho phép AS lặp lại, và vì sao CE lại không học route?

Trong MPLS Layer 3 VPN (L3VPN), phần lớn lỗi “khó chịu” không nằm ở việc thiết lập MPLS hay iBGP… mà nằm ở thứ tưởng như rất nhỏ: cơ chế phòng ngừa lặp AS (AS loop) của BGP khi chạy ở biên PE–CE.

Bạn có thể đã thấy hiện tượng rất quen:

• Route từ PE này sang PE kia (qua MPLS) vẫn đi được.
• Nhưng CE ở một phía không nhận được prefix của CE phía còn lại.
• Hoặc route “bị từ chối” trong iBGP/MP-BGP theo logic của BGP, dù bạn đã cấu hình đầy đủ VRF, RT/RD.

Lời giải thường nằm ở câu lệnh trong BGP:

allow-as-in (mà tài liệu đặt trong ngữ cảnh “BGP Allow-AS-In”).

Trong bài viết này, mình sẽ bám sát nội dung tài liệu bạn gửi: giải thích đúng cơ chế theo “vòng lặp AS” của BGP bên ngoài, phân tích topology theo đúng ví dụ, sau đó chuyển thành một walkthrough để bạn có thể hiểu và tự làm lại trên lab.


1) Vấn đề cốt lõi: BGP external loop prevention và lý do route bị chặn


Theo tài liệu, external BGP có một cơ chế đơn giản để tránh vòng lặp:
BGP không muốn nhận các route mà trong AS-path của chúng xuất hiện AS của chính mình (với ngữ cảnh “external” tức eBGP).


Nếu nhìn theo cách dễ hiểu:

• Bạn tưởng CE bên trái quảng bá prefix lên PE.
• Nhưng route đó đi qua hệ thống, và trong quá trình xử lý AS-path, BGP “nhìn thấy” rằng route có dấu hiệu đã đi vòng qua chính AS đó.
• Khi đó BGP sẽ từ chối cập nhật (reject) hoặc không đưa prefix vào bảng theo best path.

Bài viết nhấn mạnh điểm quan trọng: đôi khi bạn “bắt buộc” phải cho phép BGP đi qua vòng lặp AS một cách hợp lệ về mặt thiết kế, đặc biệt khi topology/AS-path trong lab hoặc mô hình thực tế của bạn không tương thích với giả định “không lặp AS” của BGP.
2) Topology ví dụ trong tài liệu: vì sao lại có chuyện “AS-path trùng nhau”

Trong file “MPLS Layer 3 VPN BGP Allow-AS-In”, topology có các thiết bị:

• PE1 và PE2: hai router PE của MPLS L3VPN.
• CE1 và CE2: hai router CE của khách hàng (cũng là nơi BGP với VRF xảy ra).
• P: router lõi MPLS trung gian.
• Các router CE và PE có cấu hình BGP theo VRF CUSTOMER để trao đổi route VPN qua MP-BGP (trên PE).

Một điểm then chốt trong tài liệu:

• “Above we have a MPLS VPN network where the customer is using the same AS number (12) on both sites. CE1 and CE2 will be able to use BGP network for learning each other's prefix since they are using the same AS number.”

Dịch đúng tinh thần:

• Trong bài toán, cả hai CE dùng chung cùng AS number (AS 12) cho BGP với PE.
• Bài học đặt ra tình huống: mặc định BGP sẽ chặn theo logic chống loop “external”, nên CE học route lẫn nhau có thể bị ảnh hưởng.

Nói thẳng: khi cùng AS số được sử dụng ở hai phía và route đi qua sẽ “trông giống” vòng lặp, BGP có thể từ chối.

3) Setup ban đầu (config ban đầu) theo tài liệu: PE–CE có gì đang xảy ra?

Tài liệu cung cấp phần “Configurations” để bạn test.

Nhìn vào các đoạn config bạn gửi, có thể rút ra các ý kỹ thuật chính (giữ nguyên logic theo file): 3.1 CE1 (AS 12) và CE2 (AS 12)

• CE1 khai báo BGP neighbor đến PE (ví dụ neighbor là IP loopback của PE).
• CE2 cũng vậy, nhưng cùng một AS number = 12.
• Các prefix loopback của CE được advertise vào BGP theo đúng VRF “customer” ở phía PE.

3.2 PE1 và PE2: MP-BGP theo VRF CUSTOMER và RT/RD

• PE chạy VRF cho khách hàng.
• PE1 và PE2 có cấu hình BGP với các neighbor là CE.
• Đồng thời giữa PE và PE còn có iBGP/MP-BGP để phân phối route VPN qua lõi MPLS.

Trong bài này, phần quan trọng là: PE không học/không chấp nhận đúng route từ CE một phía do cơ chế loop prevention của BGP external. Khi đó RT có thể vẫn “đủ”, nhưng route theo đường BGP bị chặn trước khi đi vào bảng VRF hoặc không được đưa qua nhánh cập nhật bạn cần.

4) Kiểm chứng bằng trạng thái BGP và bảng định tuyến: dấu hiệu “bị từ chối vì AS-path loop”

Tài liệu sau đó chuyển sang phần kiểm tra:

• Router PEs kiểm tra BGP table trước khi enable allow-as-in.
• CE router kiểm tra route có được install hay không.

Điểm then chốt mà tài liệu làm rõ bằng debug/hiển thị trạng thái:

1. CE/PE phải có sự học route thông qua iBGP/MP-BGP trong VRF.
2. Nhưng BGP bị từ chối do “AS loop prevention”.
3. Kết quả: prefix không được update/không được install, nên CE phía bên kia cũng không thấy.

Đây là lý do trong các bài MPLS L3VPN, bạn không nên chỉ nhìn RT/RD.
Bạn phải nhìn cả chuỗi thuộc tính BGP, đặc biệt là AS-path và cơ chế loop prevention.

5) Giải pháp trong tài liệu: dùng allow-as-in để vượt cơ chế loop prevention

Tài liệu đưa ra câu lệnh “đánh thẳng vào vấn đề”:

• “This lesson is about allow-AS-in so that’s what we will do this time.”

Có nghĩa là thay vì dùng các cách vòng khác (tài liệu đề cập là “override preferences” / “use AS override”), ở bài này bạn dùng đúng allow-as-in.

5.1 Hành vi của allow-as-in

Về mặt cơ chế:

• BGP thường ngăn external route có AS của chính nó trong AS-path.
• allow-as-in cho phép accept những route như vậy trong ngữ cảnh bạn cấu hình.

Bạn cấu hình lệnh này tại PE (trong ngữ cảnh BGP neighbor với CE), để đảm bảo rằng:

• Route từ CE1 (AS 12) vẫn được PE1/PE2 chấp nhận mặc dù AS-path trông như có loop.

Tài liệu mô tả rõ hướng triển khai:

• Trên CE được tạo route và PE không nhận vì loop prevention.
• Sau khi bật allow-as-in (trên PE/đúng neighbor tương ứng), route được chấp nhận, cập nhật tuyến vào RIB.

6) Walkthrough theo đúng mạch tư duy trong lab: làm từng bước để “thấy” route đi qua

Mặc dù file có nhiều đoạn show/debug, nhưng mạch thực hành bạn có thể rút thành workflow chuẩn sau (đúng tinh thần tài liệu):

Bước 1: Nhìn BGP table / RIB trước khi enable

• Trên PE, kiểm tra route từ CE phía bên kia có được đưa vào VRF không.
• Đồng thời kiểm tra AS-path/next-hop/weight (nếu tài liệu có hiển thị “metric locpref weight path”).

Điểm bạn cần “thấy”:

• prefix của CE “bị mất” hoặc không có đường được chọn/install.

Bước 2: Bật debug để xác định lý do route bị từ chối

Tài liệu có đoạn debug về BGP updates (mục đích là chứng minh “lý do bị chặn là do AS-number protection mechanism”).

Bước 3: Thêm allow-as-in theo neighbor

• Cấu hình tại PE với neighbor tương ứng (CE).
• Mục tiêu: khiến route có AS-path “đụng chính nó” vẫn đi qua được.

Bước 4: Xác nhận route install vào RIB

• Sau khi cấu hình xong, chạy lại show tương tự trong tài liệu.
• Bạn phải thấy prefix xuất hiện trong bảng định tuyến VRF của PE và tiếp theo CE sẽ thấy route.

Tài liệu kết luận bằng một đoạn “Excellent it’s working”, và sau đó tiếp tục hiển thị kết quả/hoàn tất.

7) Một ví dụ giải thích để dễ hình dung: “cùng AS hai phía” tạo cảm giác vòng lặp

Giả sử bạn có 2 site khách hàng:

• CE1 thuộc AS 12 quảng bá prefix A lên PE1.
• CE2 thuộc AS 12 quảng bá prefix B lên PE2.

Trong MPLS L3VPN:

• PE biến đổi/đóng gói route theo MP-BGP/VRF và phân phối qua lõi.
• Vấn đề là, khi route đi qua chuỗi xử lý BGP, AS-path có thể chứa AS 12 theo cách làm BGP hiểu nhầm rằng route đã “quay lại từ chính AS đó”.

Trong thiết kế có chủ đích (lab hoặc scenario thực tế), đây không phải loop “tai hại”, nhưng BGP lại xử lý theo chính sách an toàn mặc định của external BGP.

Vì vậy, allow-as-in là “cú gạt” để cho phép route đi qua dù AS-path có chứa AS tương tự theo cơ chế mặc định.

8) Kết luận theo đúng nội dung tài liệu

Phần cuối file đưa ra kết luận chính (mình diễn giải sát nghĩa):

• allow-as-in là cách đơn giản để vượt qua cơ chế external BGP loop prevention.
• Khi bạn không bật, CE/PE có thể không nhận được route do bị chặn.
• Khi bật đúng chỗ (đúng neighbor/bên đúng), route sẽ được cập nhật và có thể nhìn thấy trong bảng định tuyến.
• Bài học tiếp theo (theo tài liệu) sẽ tiếp tục mở rộng phần cơ chế/tác động khi thay đổi thuộc tính theo hướng khác.

9) Bạn nên nhớ điều gì khi đi troubleshoot MPLS L3VPN?

Nếu bạn làm lab hoặc làm thực tế và gặp lỗi kiểu:

• RT đúng nhưng route không sang CE kia,
• VRF đúng nhưng CE không thấy prefix,

Thì hãy kiểm tra theo thứ tự ưu tiên:

1. MP-BGP/VRF đã đúng chưa (RD/RT, import/export)
2. Trên PE, route có thật sự được cập nhật vào RIB của VRF không
3. Nếu có vấn đề “AS loop prevention”, cân nhắc allow-as-in (đúng ngữ cảnh external BGP)
4. Dùng debug/clear để xác nhận “lý do bị chặn” chứ không chỉ nhìn output cuối