VPN TRONG MẠNG MPLS (VPN-based MPLS) (tt)

[admin]

Tác giả:

+ Nguyễn Thị Băng Tâm

3.2.3. Hoạt động của MPLS VPN

Như đã nói ở trên, MPLS VPN là sự kết hợp các ưu điểm của cả hai mô hình overlay VPN và peer-to-peer VPN. Do đó việc lựa chọn các yếu tố cần thiết để cấu thành mạng MPLS cũng trở nên quan trong, các yếu tố đó bao gồm giao thức định tuyến, cách truyền nhãn qua mạng MPLS trong khi vẫn đảm bảo được tính chất của VPN, v.v…Ta hãy đi phân tích một số đặc điểm để cấu thành mạng MPLS VPN.

3.2.3.a. Kiến trúc của router biên PE trong mạng MPLS VPN



VPNv4 route là NLRI 96 bit (RD + 32 bit Ipv4 NLRI)
Một bảng VRF sẽ chỉ có một route VPNv4 cho tất cả các địa chỉ prefix 32 bit thuộc về VRF đó. Khi địa chỉ đích của gói tin thỏa mãn (matched) được route VPNv4 thì có nghĩa là phần prefix 32 bit trong route VPNv4 thỏa mãn địa chỉ đích đó.

Format của Route Distinguisher:

Route Distinguisher được tạo ra để cho mỗi nhà cung cấp dịch vụ có thể quản trị ‘khoảng giá trị - numbering space’ của họ, họ có thể thực hiện việc đăng kí RD mà không mâu thuẫn với việc đăng kí RD của nhà cung cấp dịch vụ khác (nghĩa là RD của mỗi nhà cung cấp dịch vụ không trùng nhau).
Format của RD bao gồm các trường: trường Type, trường Administrator , và trường Assigned number.
• Trường Type: 2 byte, xác định chiều dài của hai trường còn lại.
• Trường Administrator: dùng để nhận diện quyền của số được đăng kí (assigned number authority).
• Trường Assigned number: bao gồm số được đăng kí cho mục đích cụ thể nào đó của nhà cung cấp dịch vụ.

Tùy vào trường Type mà RD có format khác nhau, cấu trúc của giá trị này có thể là ASN : nn hoặc IP-address : nn. Với ASN là Autonomous System Number được đăng kí bởi Internet Assigned Number Authority (IANA), và nn là số được đăng kí bởi nhà cung cấp dịch vụ đến IANA. Số nn là giá trị mang tính duy nhất trên mỗi VRF, mặc dù trong môt vài trường hợp nó có thể duy nhất trên mỗi khách hàng VPN. Vậy VPN có thể có RD với trường Administrator là ASN hay IP-address. Nhưng cách sử dụng ASN được khuyến khích hơn vì nó được đăng kí bởi IANA, tạo ra được tính duy nhất giữa các nhà cung cấp dịch vụ. Sử dụng format IP-address : nn chỉ khi mạng MPLS/VPN sử dụng private AS nhưng địa chỉ VPN-Ipv4 được truyền đi không phải bị giới hạn ở private AS (ví dụ khi trao đổi VPN route giữa các nhà cung cấp dịch vụ khác nhau).
Format của RD như sau:


Hình 3.4: Khối kiến trúc của router PE

Router PE trong MPLS VPN rất giống như kiến trúc của POP trong router PE dành trước trong mô hình VPN ngang cấp, chỉ có sự khác biệt là toàn bộ mọi thứ được tập trung vào một thiết bị vật lý. Mỗi khách hàng đăng kí một bảng định tuyến độc lập nhau (bảng định tuyến ảo) tương ứng như một router ảo trong mô hình VPN ngang cấp. Định tuyến dọc mạng của nhà cung cấp được thực hiện bởi tiến trình định tuyến khác sử dụng bảng định tuyến toàn cục (global), tương đương như intra-POP-P-router trong mô hình VPN ngang cấp.

3.2.3.b. Truyền thông tin định tuyến dọc mạng nhà cung cấp

Khi bảng định tuyến ảo đảm bảo sự cách ly giữa các khách hàng, dữ liệu từ các bảng định tuyến này vẫn cần được trao đổi giữa các Router PE để dữ liệu có thể truyền giữa các site gắn vào các Router PE khác nhau. Do đó chúng ta cần phải có một giao thức định tuyến sẽ vận chuyển tất cả các route của khách hàng dọc mạng nhà cung cấp trong khi vẫn duy trì được không gian địa chỉ độc lập giữa khách hàng với nhau.

Một giải pháp được đưa ra là chạy giao thức định tuyến riêng cho mỗi khách hàng. Các router PE có thể được kết nối thông qua các đường hầm điểm – điểm (và giao thức định tuyến cho mỗi khách hàng sẽ chạy giữa các router PE) hoặc là router P có thể tham gia vào quá trình định tuyến của khách hàng. Giải pháp này, mặc dù thực hiện đơn giản nhưng lại không thích hợp trong môi trường khách hàng, vì nó không có khả năng mở rộng và phải đối mặt với nhiều vấn đề khi có yêu cầu hỗ trợ VPN trùng lắp (overlapping VPN):

o Router PE phải chạy một số lượng lớn các giao thức định tuyến .
o Router P phải mang tất cả các route của khách hàng.
o
Sau đó, một giải pháp tốt hơn được đưa ra là chỉ triển khai một giao thức định tuyến có thể trao đổi tất cả các route của khách hàng dọc mạng nhà cung cấp. Rõ ràng giải pháp này tốt hơn giải pháp trước nhưng router P vẫn phải tham gia vào định tuyến khách hàng, do đó nó vẫn không giải quyết được vấn đề mở rộng.
Để hiểu rõ hơn vấn đề mở rộng khi triển khai một giao thức định tuyến trên 1 VPN, ta lấy ví dụ sau đây: Giả sử mạng backbone của nhà cung cấp dịch vụ sẽ phải cung cấp hơn 100 khách hàng VPN kết nối đến router hai router biên PE sử dụng OSPF là giao thức định tuyến. Router PE trong mạng backbone sẽ chạy hơn 100 bản copy tiến trình định tuyến OSPF độc lập nhau với mỗi bản copy gửi các gói tin hello và gói tin refreshment tuần hoàn qua mạng. Vì có thể chạy hơn một bản copy OSPF qua cùng một link, ta có thể cấu hình các subinterface trên một VPN trên link giữa PE và CE, kết quả là tạo ra mô hình mạng phức tạp. Và phải chạy 100 thuật toán SPF cũng như duy trì database topology riêng rẽ trong các router P.
Giải pháp tối ưu là truyền thông tin định tuyến khách hàng sẽ do một giao thức định tuyến giữa các router PE điều hành, các router P không tham gia vào việc định tuyến này. Giải pháp này hiệu quả vì nó có khả năng mở rộng:
• Số lượng giao thức định tuyến giữa các router PE không tăng khi tăng số lượng khách hàng.
• Router P không mang các route của khách hàng.
Do đó yêu cầu bây giờ là việc lựa chọn giao thức định tuyến nào sẽ chạy giữa các router PE. Khi tổng số route của khách hàng rất lớn, nên chỉ có một giao thức định tuyến mới có khả năng đảm bảo được vấn đề này là BGP. BGP được sử dụng trong mạng MPLS/VPN trên các router PE để vẫn chuyển các route của khách hàng. Giao thức BGP dùng trong mạng MPLS/VPN được gọi là Multiprotocol BGP (MP-BGP).
Ta có thể tóm tắt các ưu điểm của BGP để chọn nó là giao thức dùng cho việc vận chuyển các VPN route là:

• VPN route trong mạng có thể tăng lên đáng kể với số lượng lớn. BGP là giao thức định tuyến có thể hỗ trợ số lượng lớn các route như vậy.
• BGP, EIGRP, ISIS cũng là các giao thức định tuyến mang thông tin định tuyến cho nhiều lớp địa chỉ khác nhau. Nhưng ISIS và EIGRP không có khả năng mở rộng, không mang được một số lượng lớn các route như BGP. BGP cũng được thiết kế để trao đổi thông tin định tuyến giữa các router không kết nối trực tiếp. Đặc điểm này hỗ trợ việc giữ thông tin định tuyến không cho các router P biết.

3.2.3.c. Bảng định tuyến và chuyển tiếp VPN ( VPN routing forwarding - VRF)

Sự kết hợp giữa bảng định tuyến VPN và bảng chuyển tiếp VPN tạo thành bảng định tuyến chuyển tiếp VPN (VRF).
Mỗi VPN đều có bảng định tuyến và chuyển tiếp riêng của nó trong router PE, mỗi router PE duy trì một hoặc nhiều bảng VRF. Mỗi site mà có router PE gắn vào đó sẽ liên kết với một trong các bảng này. Địa chỉ IP đích của gói tin nào đó chỉ được kiểm tra trong bảng VRF mà nó thuộc về nếu gói tin đến trực tiếp từ site tương ứng với bảng VRF đó. Một VRF đơn giản chỉ là một tập hợp các route thích hợp cho một site nào đó (hoặc một tập hợp gồm nhiều site) kết nối đến router PE. Các route này có thể thuộc về hơn một VPN.
Vậy các bảng VRF được phổ biến như thế nào ?

Ví dụ, giả sử có 3 router PE là PE1, PE2, PE3, và 3 router CE là CE1, CE2, CE3. Giả sử PE1 học từ CE1 các route hợp lệ ở site CE1. PE2 và PE3 thứ tự gắn vào site CE2 và CE3. Cả ba site này đều thuộc cùng một VPN V, thì PE1 sẽ sử dụng BGP để phân phối cho PE2 và PE3 các route mà nó học được từ site CE1. PE2 và PE3 sử dụng các route này để đưa vào bảng chuyển tiếp dành cho site CE2 và CE3. Các route từ những site không thuộc vào VPN V sẽ không xuất hiện trong bảng chuyển tiếp này, có nghĩa là các gói tin từ CE3 và CE2 không thể được gửi đến những site nào không thuộc VPN V.
Nếu một site thuộc vào nhiều VPN, bảng chuyển tiếp tương ứng với site đó có thể có nhiều route liên quan đến tất cả VPN mà nó thuộc về. PE chỉ duy trì một bảng VRF trên một site. Các site khác nhau có thể chia sẽ cùng bảng VRF nếu nó sử dụng tập hợp các route một cách chính xác giống như các route trong bảng VRF đó. Nếu tất cả các site có thông tin định tuyến giống nhau (điều này thường là các site đó cùng thuộc về tập hợp VPN) sẽ được phép liên lạc trực tiếp với nhau và nếu kết nối đến cùng một router PE sẽ được đặt vào cùng một bảng VRF chung.

Giả sử router PE nhận được gói tin từ một site gắn trực tiếp vào nó, gọi site này là siteA nhưng địa chỉ đích của gói tin không có trong tất cả các entry có trong bảng chuyển tiếp tương ứng với siteA. Nếu nhà cung cấp dịch vụ không cung cấp truy cập Internet cho siteA thì gói tin sẽ bị loại bỏ vì không thể phân phối được đến đích, nhưng nếu nhà cung cấp dịch vụ có cung cấp truy cập Internet cho siteA thì lúc này địa chỉ đích của gói tin sẽ được tìm kiếm trong bảng định tuyến global. Do đó bất kì router PE nào trong mạng MPLS/VPN có nhiều bảng định tuyến trên mỗi VRF và một bảng định tuyến global, bảng định tuyến này được sử dụng để tìm các router khác trong mạng nhà cung cấp dịch vụ, cũng như tìm các đích thuộc về mạng bên ngoài (ví dụ như Internet).

Tóm lại, VRF là một trường hợp (instance) định tuyến và chuyển tiếp có thể được sử dụng cho một site VPN hoặc cho nhiều site kết nối đến cùng một router PE miễn là các site này chia sẽ chính xác các yêu cầu kết nối giống nhau. Do đó cấu trúc của bảng VRF có thể bao gồm :

• Bảng định tuyến IP.
• Bảng chuyển tiếp.
• Tập hợp các quy tắc và các tham số giao thức định tuyến (gọi là routing protocol context).
• Danh sách các interface sử dụng trong VRF.

3.2.3.d. Phân phối route VPN thông qua BGP

Với việc triển khai một giao thức định tuyến là BGP để trao đổi tất cả các route của khách hàng giữa các router PE, một vấn đề được đặt ra là: làm thế nào mà BGP có thể truyền nhiều prefix xác định thuộc về các khách hàng khác nhau giữa các router PE?
Như ta đã biết BGP, trong format chuẩn của nó, chỉ có thể thực hiện được đối với các route IPv4. Trong MPLS/VPN, vì mỗi VPN phải có khả năng sử dụng (mặc dù điều này không cần thiết) các IP prefix giống nhau như các VPN khác (ngay cả khi chúng không liên lạc với nhau). BPG sử dụng địa chỉ IPv4 chọn một đường đi giữa tất cả các đường có thể đi đến đích (gồm có network và mask). Do đó, MP-BGP không thể làm việc đúng nếu khách hàng sử dụng cùng không gian địa chỉ.

Chỉ có một giải pháp để giải quyết vấn đề này là mở rộng ip prefix khách hàng với một prefix duy nhất sẽ làm cho địa chỉ của khách hàng trở nên duy nhất ngay cả khi có sự trùng lắp địa chỉ. Hơn nữa ta phải đảm bảo rằng chính sách được sử dụng để quyết định route nào trong số các route được BGP sử dụng chỉ có thể có ở trong bảng VRF mà nó phải thuộc về.
Việc truyền route của khách hàng dọc mạng MPLS VPN sẽ được thực hiện như sau:

• Router CE gửi cập nhật định tuyến Ipv4 đến Router PE.
• Router PE sau đó thêm vào Route Distinguisher 64 bit vào cập nhật định tuyến Ipv4 mà nó đã nhận đó, kết quả là tạo ra địa chỉ VPNv4 96 bit duy nhất.
• Địa chỉ VPNv4 này được truyền đi thông qua phiên MP-IBGP đến các Router PE khác.
• Router PE nhận sẽ loại bỏ Route Distinguisher từ địa chỉ VPNv4 tạo thành địa chỉ Ipv4 như ban đầu mà CE đầu xa đã gửi.
• Địa chỉ Ipv4 này được chuyển tiếp đến router CE khác trong bản cập nhật định tuyến Ipv4.

3.2.3.e. Route Distinguisher (RD)

Một prefix 64 bit, được gọi là Route Distinguisher, được sử dụng trong MPLS VPN để biến đổi địa chỉ IP 32 bit (là địa chỉ không duy nhất) thành địa chỉ 96 bit (là địa chỉ mang tính duy nhất). Địa chỉ 96 bit này sẽ đựơc truyền giữa các router PE và được gọi là địa chỉ VPNv4 (hay còn gọi là địa chỉ VPN_Ipv4). Route distinguisher bản thân nó không có ý nghĩa hay giá trị gì cả, nó không có mang thông tin về nguồn gốc của route hoặc về tập hợp các VPN mà route đó được phân phối tới. Mục đích của RD chỉ là cho phép tạo ra tính duy nhất cho các route có địa chỉ Ipv4. RD cũng có thể được sử dụng để tạo ra nhiều route khác nhau trong cùng một hệ thống.

Format của địa chỉ VPNv4 :



VPNv4 route là NLRI 96 bit (RD + 32 bit Ipv4 NLRI)
Một bảng VRF sẽ chỉ có một route VPNv4 cho tất cả các địa chỉ prefix 32 bit thuộc về VRF đó. Khi địa chỉ đích của gói tin thỏa mãn (matched) được route VPNv4 thì có nghĩa là phần prefix 32 bit trong route VPNv4 thỏa mãn địa chỉ đích đó.

Format của Route Distinguisher:

Route Distinguisher được tạo ra để cho mỗi nhà cung cấp dịch vụ có thể quản trị ‘khoảng giá trị - numbering space’ của họ, họ có thể thực hiện việc đăng kí RD mà không mâu thuẫn với việc đăng kí RD của nhà cung cấp dịch vụ khác (nghĩa là RD của mỗi nhà cung cấp dịch vụ không trùng nhau).
Format của RD bao gồm các trường: trường Type, trường Administrator , và trường Assigned number.

• Trường Type: 2 byte, xác định chiều dài của hai trường còn lại.
• Trường Administrator: dùng để nhận diện quyền của số được đăng kí (assigned number authority).
• Trường Assigned number: bao gồm số được đăng kí cho mục đích cụ thể nào đó của nhà cung cấp dịch vụ.

Tùy vào trường Type mà RD có format khác nhau, cấu trúc của giá trị này có thể là ASN : nn hoặc IP-address : nn. Với ASN là Autonomous System Number được đăng kí bởi Internet Assigned Number Authority (IANA), và nn là số được đăng kí bởi nhà cung cấp dịch vụ đến IANA. Số nn là giá trị mang tính duy nhất trên mỗi VRF, mặc dù trong môt vài trường hợp nó có thể duy nhất trên mỗi khách hàng VPN. Vậy VPN có thể có RD với trường Administrator là ASN hay IP-address. Nhưng cách sử dụng ASN được khuyến khích hơn vì nó được đăng kí bởi IANA, tạo ra được tính duy nhất giữa các nhà cung cấp dịch vụ. Sử dụng format IP-address : nn chỉ khi mạng MPLS/VPN sử dụng private AS nhưng địa chỉ VPN-Ipv4 được truyền đi không phải bị giới hạn ở private AS (ví dụ khi trao đổi VPN route giữa các nhà cung cấp dịch vụ khác nhau).

Format của RD như sau:



Ví dụ về việc sử dụng RD đã giải quyết được vấn đề trùng địa chỉ Ipv4:



Hình 3.5: Sử dụng RD đã giải quyết được vấn đề trùng địa chỉ giữa các VPN

Trên hình vẽ trên, router PE3 nhận hai cập nhật về mạng 10.2.1.0/24 từ hai router PE là PE1 và PE2, nhờ vào RD mà các cập nhật này mang tính duy nhất. Cập nhật được nhận từ router PE1 là cho prefix 100:27:10.2.1.0/24 và cập nhật được nhận từ router PE2 là cho prefix 100:26:10.2.1.0/24.

[admin]

(tt)

3.2.3.f. Route Target (RT)

Mặc dù Route Distinguisher cho phép khách hàng VPN sử dụng cùng chung một không gian địa chỉ mạng riêng, nhưng nó không giải quyết được vấn đề khi có nhiều khách hàng trong cùng một VPN sử dụng chung không gian địa chỉ ở site của họ cũng như khi một site thuộc về nhiều VPN vì mỗi RD chỉ ánh xạ đến một VPN (ánh xạ một-một). Do đó cần có một phương pháp khác dùng để nhận dạng VPN và xác định một route nào đó thuộc về VPN nào.
Khái niệm Route Target ra đời để giải quyết vấn đề đó.
Chức năng được thực hiện bởi Route Target tương tự như chức năng được thực hiện bởi thuộc tính BGP Community. Tuy nhiên, format của thuộc tính BGP Community không thích hợp, vì nó chỉ có hai byte dành cho khoảng giá trị (numbering space). Do đó cần phải mở rộng thuộc tính Community để cung cấp khoảng giá trị lớn hơn. Và thuộc tính này được gọi là BGP Community mở rộng (extended BGP Community).
Thuộc tính BGP Community mở rộng trong các cập nhật định tuyến được sử dụng để mang Route Target của cập nhật đó, từ đó sẽ xác định được cập nhật thuộc về VPN nào. Do đó, Route Target chính là thuộc tính được gắn vào VPNv4 route.

Mỗi bảng VRF sẽ được kết hợp với một hay nhiều thuộc tính Route Target. Khi route VPNv4 được Router PE tạo ra, nó sẽ được kết hợp với một hay nhiều thuộc tính Route Target. Bất kì route nào mang Route Target T sẽ được phân phối đến mỗi router PE có bảng chuyển tiếp VRF có Route Target T. Khi PE nhận được một route như vậy nó được cập nhật vào bảng VRF mà Route Target đó đã nhận diện (vì mỗi VPN chỉ có một bảng VRF).
MPLS/VPN Route Target được gắn đến route của khách hàng tại thời điểm route đó được router PE chuyển đổi từ route IPv4 thành route VPNv4 được gọi là RT xuất (export RT). RT xuất được cấu hình riêng biệt cho mỗi bảng VRF trong router PE và nó sẽ nhận diện được VPN của site có bảng VRF đó.
Khi route VPNv4 được truyền đến router PE khác, các router đó cần lựa chọn route để nhập vào bảng VRF. Sự lựa chọn này dựa vào RT nhập (import RT). Mỗi bảng định tuyến ảo trong router PE có thể có một số RT nhập được cấu hình để nhận diện route đến là thuộc VPN nào, sau đó sẽ nhập route đó vào bảng định tuyến ảo tương ứng.

Vậy làm cách nào mà router PE có thể xác định thuộc tính Route Target nào kết hợp vào với route được cho? Có nhiều giải pháp đưa ra để thực hiện điều này. PE có thể được cấu hình để liên kết tất cả các route đến một site nào đó với một giá trị Route Target. Hoặc PE có thể được cấu hình để liên kết một số route nào đó đến site ta quan tâm với một giá trị Route Target. Hoặc router CE, khi nó phân phối các route này đến router PE (sẽ được phân tích chi tiết ở sau), có thể chỉ ra một hoặc nhiều Route Target cho route đó.
Ví dụ:



Hình 3.6: Sử dụng RT khi một site tham gia vào nhiều hơn một VPN

Router PE1 trong mạng MPLS xuất các route cho VPN Blue với Route Target là 100 : 26 và cho VPN Red với Route Target là 100 : 27. VRF Green trên router PE3 trong mạng MPLS sẽ nhập các route với Route Target là 100 : 27, có nghĩa là nó chỉ nhập các route cho site RCE1 của Red. Còn bảng VRF Blue trên router PE2 chỉ nhập các route với Route Target là 100 : 26 và 100 : 27, tức là nó nhập các route cho site BCE1 và cho site RCE1.
Trong ví dụ 3.6 cũng cho thấy một site trong một VPN có thể giữ nhiều route, các route này có thể không có trong site khác cũng thuộc về chung một VPN, bảng VRF ở mỗi site là khác nhau cho dù chúng có cùng thuộc một VPN đi chăng nữa. Router PE2 nhập các route với Route Target là 100 : 26 và 100 : 27, nghĩa là site Blue BCE2 có các route thuộc về site RCE1 và site BCE1. Nhưng trên router PE1 sẽ không nhận được route nào từ 2 site nói trên vì nó không được cấu hình để nhập các route. Nó chỉ có các route thuộc về VPN mà nó đang tham gia vào vì router PE2 không quảng bá lại các route có trong bảng VRF của nó theo quy tắc của BGP.

3.2.3.g. Route origin

Route Target xác định được VRF nào, và do đó xác định được VPN site nào, sẽ nhận được route Mặc dù Route Target cung cấp cơ chế để nhận diện VRF nhưng nó không cung cấp tiện ích có thể ngăn được loop định tuyến. Loop này có thể xảy ra nếu route được học từ một site và lại quảng bá ngược trở lại site đó. Để ngăn chặn điều này, một khái niệm khác được giới thiệu trong MPLS/VPN đó là Route Origin (RO), RO nhận diện route xuất phát từ site nào, và từ đó site đó không nên nhận route từ bất kì router PE. Nhưng nếu mạng backbone MPLS/VPN được thiết kế theo kiểu partitioned site (multihomed) thì không cần phải sử dụng Route Origin, vì trong trường hợp này, các route được học từ một phần của site sẽ được quảng bá đến phần khác cũng thuộc về site đó nhưng trên router PE ở vị trí khác.
Route Origin là một thuộc tính thuộc về thuộc tính Community mở rộng giống như Route Target. Nó được sử dụng để ngăn chặn loop khi thuộc tính AS_Path không thể sử dụng.

3.2.3.h. Giao thức MP-BGP (Multiprotocol BGP)

• Thuộc tính Community mở rộng (Extended Community)
Ta đã biết thuộc tính BGP Community mở rộng được sử dụng để làm gì trong mạng MPLS/VPN. Bây giờ ta đi tìm hiểu cấu trúc của nó.
Thuộc tính community mở rộng là một community được định nghĩa mang code 16 và được mã hóa thành giá trị 8 byte. Có format giống như Route Distinguisher. Hai octet đầu tiên định nghĩa loại thuộc tính, 6 octet tiếp theo là giá trị của thuộc tính.

Type mang giá trị từ 0 đến 0x7FFF được IANA đăng kí.
Type mang giá trị từ 0x8000 đến 0xFFFF là dành cho vendor.

Route Target community mở rộng có type code là 0x0002 và 0x0102, Route Origin community mở rộng có type code là 0x0001 và 0x0101.
Cấu trúc của trường giá trị như thế nào là phụ thuộc vào giá trị ở trường type.

Nếu trường Type mang giá trị là 0x00 thì nó có cấu trúc sau: ASN : nn



Nếu trường Type mang giá trị là 0x01 thì nó có cấu trúc là: Ip-add: nn



Multiprotocol BGP (MP-BGP)

MP- BGP là giao thức mở rộng của BGP. Nó được sử dụng để quảng bá các route VPN khách hàng giữa các router PE, các route được PE học được từ router CE kết nối trực tiếp vào nó.

MP-BGP chỉ yêu cầu trong mạng backbone của nhà cung cấp dịch vụ. Do đó, tất cả các phiên MP-BGP đều là internal, vì phiên được thiết lập giữa hai router thuộc về cùng một AS. Do đó ta có thể gọi giao thức này là MP-iBGP.
MP-BGP được yêu cầu trong kiến trúc MPLS/VPN vì cập nhật BGP cần mang nhiều thông tin hơn bên cạnh địa chỉ Ipv4 như BGP-4. Và BGP mở rộng cung cấp nhiều khả năng (capability) thêm vào cần thiết để cho phép BGP mang nhiều thông tin hơn. Khi phiên BGP được thiết lập giữa hai router BGP, việc trao đổi bản tin Open khởi tạo các tham số BGP, các tham số đó như là giá trị AS (AS-number) được sử dụng bởi láng giềng. Bản tin này cũng có thêm nhiều tham số lựa chọn (xem format của bản tin Open trong phần Bản tin BGP), một trong các tham số lựa chọn đó là Capabilities. Một trong các Capabilities đó là multiprotocol extensions. Các multiprotocol extensions này cung cấp cho BGP khả năng mang thêm nhiều thông tin khác ngoài địa chỉ Ipv4 trong các cập nhật định tuyến.

Multiprotocol extensions sử dụng hai thuộc tính mới là Multiprotocol Reachable NLRI (MP-REACH_NLRI) và Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI).
MP_REACH_NLRI được sử dụng để mang thông tin về các đích hợp lệ (reachable) với thông tin về next-hop sử dụng để chuyển tiếp gói tin đến các đích đó.
MP_UNREACH_NLRI được sử dụng để mang thông tin về các đích không hợp lệ (unreachable).
Cả hai thuộc tính nói trên là đều là thuộc tính optional non-transitive, có nghĩa là nếu router BGP nào không hỗ trợ multiprotocol capabilities sẽ bỏ qua thông tin được mang trong các thuộc tính này, và sẽ không chuyển nó đến router BGP khác.

• MP_REACH_NLRI (type code 14):
Thuộc tính MP_REACH_NLRI được sử dụng cho các mục đích sau:
o Để quảng bá route khả thi đến router ngang cấp.
o o Để cho phérouter P quảng bá địa chỉ NLRI như là next-hop.
• Thông tin có trong MP_REACH_NLRI bao gồm:
o o Thông tin về address-family
o o Thông tin next-hop
o o NLRI
• Format bao gồm các trường sau (chỉ nêu ra những trường quan trọng trong MPLS/VPN):
o o Address Family Identifier (AFI): 2 octet, dùng để nhận diện giao thức lớp mạng được mang trong cập nhật định tuyến.
o o Subsequent AFI: 1 octet, trường này cung cấp thông tin thêm vào cho NLRI được mang trong attribute, trong MPLS VPN thì thông tin thêm đó là nhãn.
• Trong trường hợp MPLS/VPN sẽ thiết lập AFI = 1 và sub-AFI = 128.
o o Length of Next-hop Network Address: 1 octet, cho biết chiều dài của địa chỉ mạng của next-hop.
o o Network Address of Next-hop: trường này có chiều dài thay đổi, bao gồm địa chỉ của next-horouter P trên đường đi đến đích. Trong trường hợp MPLS/VPN thì đây là router PE quảng bá route.
o o NLRI: có chiều dài thay đổi cho biết các NLRI cho các route khả thi được quảng bá trong attribute này. NLRI được định nghĩa trong BGP bao gồm prefix và chiều dài prefix (prefix length). Prefix đại diện cho địa chỉ đích hợp lệ, đang tồn tại và prefix length đại diện cho số bit được thiết lập trong subnet mask. Ví dụ, mạng 10.1.1.0 255.255.255.0 có prefix là 10.1.1.0 và prefix length là 24. Có 24 bit được thiết lập trong subnet mask, do đó nó sẽ được quảng bá bởi BGP là 10.1.1.0/24. NLRI được biểu diễn dưới dạng <length, prefix>.
o
• Tuy nhiên, trong MP-BGP thì NLRI được sử dụng để mang thông tin ánh xạ nhãn. Nhãn được mã hóa trong trường NLRI của attribute Multiprotocol Extensions, và trường SAFI được sử dụng để thông báo cho biết NLRI có mang nhãn.
NLRI được mã hóa thành một hoặc 3 triple với format sau <nhãn, chiều dài, prefix>:
o Chiều dài : tổng chiều dài của nhãn cộng với prefix (có cả RD).
o Nhãn: 24 bit, mang một hoặc nhiều nhãn trong stack, mặc dù cập nhật BGP chỉ có một nhãn.
o Prefix: gồm có Route Distinguisher và Ipv4 prefix.
MP_UNREACH_NLRI (type code 15):

• Đây là thuộc tính có thể được sử dụng cho mục đích thu hồi các route không còn khả thi. Thuộc tính này bao gồm một hay nhiều bộ ba <Address Family Infomation, Unfeasible Routes Length, Withdrawn Routes>, trong đó mỗi bộ ba được mã hóa theo những trường sau:

o Trường Address Family Identifier (AFI): trường này mang bộ nhận diện của giao thức lớp mạng liên kết với NLRI theo sau đó.
o Trường Subsequent Address Family Identifier: trường này cung cấp thông tin phụ thêm về loại NLRI được mang trong attribute.
o Withdrawn Route: trường này có chiều dài thay đổi, nó được sử dụng để cho biết danh sách NLRI cho các route bị thu hồi.

• Bản tin cập nhật có MP_UNREACH_NLRI không cần phải mang các thuộc tính khác. BGP speaker có thể thu hồi các route đã quảng bá trước đó (cũng như ánh xạ route này với nhãn) bằng cách hoặc là (a) quảng bá một route mới (và nhãn) với cùng NLRI như route đã được quảng bá trước đó, hoặc (b) ghi NLRI của route đã quảng bá trước đó vào trường Withdrawn Routes của bản tin Update. Thông tin nhãn được mang trong trường Withdrawn Routes (thông tin này là một phần của NLRI) sẽ được thiết lập thành 0x800000 (dĩ nhiên lúc này phiên BGP cũng thu hồi tất cả các route đã quảng bá trước đó).
Router BGP có thể duy trì (và quảng bá đến BGP ngang cấp với nó) nhiều hơn một route đến cùng một đích, miễn là route đó đều có nhãn của nó. Việc mã hóa đã nêu ở trên cho phép một bản tin Update mang nhiều route, mỗi route có nhãn của riêng nó. Trong trường hợp này, nếu một route bị thu hồi, và nhãn được chỉ rõ tại thời điểm bị thu hồi, chỉ có route tương ứng với nhãn tại thời điểm đó bị thu hồi. Nếu route bị thu hồi, và không có nhãn nào được chỉ rõ tại thời điểm bị thu hồi, thì chỉ có route không có nhãn tại lúc đó bị thu hồi, lúc này nhãn của route đó bị loại bỏ.

[hieu1506]

ai làm ơn post lại mấy cái ảnh trong bài viết giùm em với :((, chẳng nhìn được gì cả :((