Tweet
SV Thực hiện : Huỳnh Thành Trung
Link bài trước:http://vnpro.org/forum/showthread.ph...-về-mpls-vpn
2.2.Hoạt động của kiến trúc MPLS/VPN:
2.2.1.Mô hình định tuyến MPLS/VPN:
-Giả sử chúng ta có 1 tình huống như thế này : Một nhà cung cấp dịch vụ SuperCom có 2 đại lý – 2 đại lý đó được đấu nối vào một core router.Mô hình như hình dưới:
-Địa chỉ cho thành phần tương ứng của mô hình trên, các trụ sở chính dùng IP public các chi nhánh dùng IP Private:
-Vấn đề trùng địa chỉ trong ví dụ trên thường là kết quả từ việc sử dụng địa chỉ dành riêng trong mạng khách hàng, đây là một trong những trở ngại chính để triển khai mạng ngang hàng. Công nghệ MPLS/VPN cung cấp giải pháp khá tốt cho vấn đề nan giải này là : “Mỗi VPN sẽ có một bảng định tuyến và chuyển tiếp trên router – vì vậy mổi khách hàng hay mỗi site khách hàng thuộc VPN đó được cung cấp khả năng truy cập một tập các bảng định tuyến chứa trong bảng đó”. Các router PE trong mạng MPLS/VPN sẽ mang bảng định tuyến tương ứng mỗi VPN và bảng định tuyến ra ngoài internet – được dùng để tìm những router khác trong mạng nhà cung cấp hay các đích tới bên ngoài internet. Và kết quả thực tế là rất nhiều router ảo được tạo trong một router vật lý.
-Ý tưởng của việc tạo ra router ảo cho phép khách hàng có khả năng dùng địa chỉ dành riêng lẫn dùng chung trong mỗi VPN. Mổi site khách hàng thuộc cùng một VPN liên quan, vì vậy yêu cầu duy nhất cho ý tưởng này là không gian địa chỉ phải là duy nhất với VPN đó. Những địa chỉ duy nhất đó ko cần thiết giữa tất cả các VPN mà chỉ cần khi giữa 2 VPN có cùng không gian địa chỉ dùng riêng để giao tiếp
-Có nhiều cấu trúc liên quan tới mỗi router ảo hơn chỉ mỗi bảng định tuyến IP ảo :
H.22.Các router ảo được tạo trong PE router
-Sự kết hợp giữa bảng định tuyến VPN và bảng chuyển tiếp IP VPN gọi là VRP (VPN routing and forwarding)
2.2.2.VRF- Virtual Routing and Forwarding Table
-Khách hàng được phân biệt trên router PE bằng các bảng định tuyến ảo (virtual routing tables) hoặc các instance, còn được gọi là VRF (Virtual Routing and Forwarding table/instances). Thực chất nó giống như duy trì nhiều router riêng biệt cho các khách hàng kết nối vào mạng của nhà cung cấp. Chức năng của VRF giống như một bảng tin định tuyến toàn cục, ngoại trừ việc nó chứa mọi tuyến liên quan đến một VPN cụ thể. VRF cũng chứa một bảng chuyển tiếp CEF cho VRF riêng biệt (VRF-specific CEF forwarding table) tương ứng với bản CEF toàn cục xác định các yêu cầu kết nối và các giao thức cho mỗi site khách hàng kết nối trên một router PE. VRF xác định giao thức định tuyến tham gia vào một VPN cụ thể cũng như giao tiếp trên router PE cục bộ tham gia vào VPN. Giao tiếp tham gia vào VRF phải hỗ trợ chuyển mạch CEF. Một VRF có thể gồm một giao tiếp (logical hay physical) hoặc nhiều giao tiếp trên một router.
-VRF chứa một bảng định tuyến IP tương ứng với bảng định tuyến IP toàn cục, một bảng CEF, liệt kê các giao tiếp tham gia vào VRF, và một tập hợp các nguyên tắc xác định giao thức định tuyến trao đổi với các router CE (routing protocol contexts). VRF còn chứa các định danh VPN (VPN identifier) như thông tin thành viên VPN (RD và RT). Hình sau cho thấy chức năng của VRF trên một router PE thực hiện tách tuyến khách hàng.
H.23. VRF tách tuyến khách hàng
-Cisco IOS hỗ trợ các giao thức định tuyến khác nhau như những tiến trình định tuyến riêng biệt (OSPF, EIGRP…) trên router. Tuy nhiên, một số giao thức như RIP và BGP, IOS chỉ hỗ trợ một instance của giao thức định tuyến. Do đó, thực thi định tuyến VRF bằng các giao thức này phải tách riêng hoàn toàn các VRF với nhau. Bối cảnh định tuyến (routing context) được thiết kế để hỗ trợ các bản sao của cùng giao thức định tuyến VPN PE-CE. Các bối cảnh định tuyến này có thể được thực thi như các tiến trình riêng biệt (OSPF), hay như nhiều instance của cùng một giao thức định tuyến (BGP, RIP,…). Nếu nhiều instance của cùng một giao thức định tuyến được sử dụng thì mỗi instance có một tập các tham số của riêng nó.
-Hiện tại, Cisco IOS hỗ trợ RIPv2, EIGRP, BGPv4 (nhiều instance), và OSPFv2 (nhiều tiến trình) được dùng cho VRF để trao đổi thông tin định tuyến giữa CE và PE. Chú ý rằng: các giao tiếp VRF có thể là luận lý (logical) hoặc vật lí (physical) nhưng mỗi giao tiếp chỉ được gán với một VRF.
Cấu hình VRF cơ bản:
-Khi cấu hình VRF là ISP cấu hình cho khách hàng của họ có thể nhận route từ các PE. ISP đính kèm VRF trên mổi PE trong đường trục MPLS/VPN để các site có thể nhận route từ VPN của mình vì vậy các tất cả PE phải có các cấu hình VRF liên quan cho VPN tương ứng
-Lệnh được sử dụng trong mode config – cú pháp : ip vrf [vrfname] trong đó [vrfname] tên site ta muốn truyền route
R1(config)#ip vrf FastFood
R1(config-vrf)#
2.2.3.Overlapping VPN:
-Trong ví dụ trên dường như làm cho ta tin rằng một VPN được liên kết với một VRF đơn trong PE. Điều đó sẽ đúng trong trường hợp VPN của khách hàng ko kết nối với 1 khách hàng khác – Chính vấn đề nảy sinh này làm cho nó trở nên phức tạp hơn và yêu cầu phải nhiều hơn VRF trên mỗi VPN khách hàng.
-Tưởng tượng rằng ISP trong ví dụ trên muốn mở rộng dịch vụ của họ và cung cấp VoIP với cổng kết nối ra những mạng voice công cộng. Cổng kết nối của VoIP được đặt trong những VPN tách biệt để tăng độ bảo mật của dịch vụ này
H24.Mô hình Voice Gateway
H25.IP voice tương ứng
-Cả 2 khách hàng là EuroBank và FastFood quyết định sử dụng dịch vụ đó nhưng chỉ với trụ sở chính còn các chi nhánh ko cần thiết cho các hoạt động voice quốc tế. yêu cầu của 2 khách hàng trên dẫn đến 1 điều khá thú vị là: “ cả 2 trụ sở chính của 2 tổ chức đó phải ở cùng lúc trong 2 VPN khác nhau” : “một là của chính tổ chức của mình và hai là phải cùng VoIP VPN để có thể liên lạc với VoIP gateway”
H26.Mô hình VPN chồng lên nhau
-Để hỗ trợ cho kiểu kết nối như trên . Kiến trúc MPLS/VPN hỗ trợ ý tưởng “sites” – khi mà VPN được tạo thành từ bởi một hay đa sites. VPN lúc này cơ bản là một tập hợp các site chia sẻ thông tin định tuyến chung – có nghĩa là một site có thể thuộc một hay nhiều VPN nếu nó nắm giữ thông tin định tuyến từ những VPN riêng biệt. Do đó VPN trong kiến trúc MPLS/VPN có thể được mô tả như một cộng đồng chung hay là những nhóm riêng, được quyết định bởi khả năng hiển thị mà các site có.
-Ý tưởng VRF phải được sửa đổi lại để hỗ trợ khái niệm “sites” – một khái niệm ko dừng lại VPN đơn mà là đa VPN. Ta lấy ví dụ như mô hình trên , không thể nào 2 hội sở FastFood và EuroBank lại có cùng VRF như tất cả các site con của mình khi kết nối vào cùng PE. Cụ thể hơn , ta thấy hội sở EuroBank cần phải truy xuất được VoIP gateway vì vậy các định tuyến tới gateways đó phải có trong VRF cho site hội sở chính trong khi VRF của site Chartres sẽ ko có các route đó. Vì vậy kiến trúc MPLS phân loại ý tưởng VRF lẻ từ khái niệm VPN
Mối quan hệ giửa các VPN, site , VRF có thể summarized theo quy tắc sau:
H27.Bảng Sumary của VRF
2.2.4.Route Targets
-Route targets (RTs) là những định danh dùng trong MPLS VPN domain khi triển khai MPLS VPN nhằm xác định thành viên VPN của các tuyến được học từ các site cụ thể. RT được thực thi bởi các BGP community mở rộng sử dụng 16 bit cao của BGP ecxtended community (64 bit) mã hóa với một gí trị tương ứng với thành viên VPN của site cụ thể. Khi một tuyến VPN học từ một CE chèn vào VPNv4 BGP, một danh sách các thuộc tính community mở rộng cho VPN router target được kết hợp với nó. Export RT dùng để xác định thành viên VPN và được kết lớp với mỗi VRF. Export RT được nối thêm vào địa chỉ khách hàng (customer prefix) khi chuyển thành địa chỉ VPNv4 bởi PE và quảng bá trong các cập nhật MP-BGP. Import RT kết hợp với mỗi VRF và xác định các tuyến VPNv4 được thêm vào VRF cho khách hàng cụ thể. Định dạng của RT giống như giá trị RD. Sự tương tác của RT và giá trị RD trong MPLS VPN domain khi cập nhật được chuyển thành cập nhật MP-BGP
H28.Hình cập nhật MP-BGP
-Khi thực thi các cấu trúc mạng VPN phức tạp (như: extranet VPN, Internet access VPNs, network management VPN,…) sử dụng công nghệ MPLS VPN thì RT giữ vai trò nồng cốt. Một địa chỉ mạng có thể được kết hợp với một hoặc nhiều export RT khi quảng bá qua mạng MPLS VPN. Như vậy, RT có thể kết hợp với nhiều site thành viên của nhiều VPN.
-Các tiến trình sau xảy ra trong suốt quá trình quảng bá tuyến trong một MPLS VPN như hình trên:
(1) Mạng 172.16.10.0/24 được nhận từ CE1-A, tham gia vào VRF CustomerA trên PE1-AS1.
(2) PE1 kết hợp một giá trị RD 1:100 và một giá trị export RT 1:100 khi cấu hình cho VRF trên bộ định tuyến PE1-AS1.
(3) Các tuyến học từ CE1-A được phân phối vào tiến trình MP-BGP trên PE1-AS1 với prefix 172.16.10.0/24 và thêm vào đầu giá trị RD 1:100 và nối thêm export RT 1:100 để gửi đi địa chỉ VPNv4 khi tham gia cập nhật MP-iBGP giữa các PE.
-Nhãn VPN (3 byte) được gán cho mỗi địa chỉ học từ các tiến trình của CE kết nối trong một VRF từ tiến trình MP-BGP của PE. MP-BGP chạy trong miền MPLS của nhà cung cấp dịch vụ nên mang theo địa chỉ VPNv4 (Ipv4 + RD) và BGP RT.
Lưu ý: mặc dù RT là cấu hình bắc buộc trong một MPLS VPN cho mọi VRF trên một bộ định tuyến, giá trị RT có thể được dùng để thực thi trên cấu trúc mạng VPN phức tạp, trong đó một site có thể tham gia vào nhiều VPN. Giá trị RT còn có thể dùng để chọn tuyến nhập vào VRF khi các tuyến VPnv4 được học trong các cập nhật MP-iBGP. Nhãn VPN chỉ được hiểu bởi egress PE (mặt phẳng dữ liệu) kết nối trực tiếp với CE quảng cáo mạng đó. Các trạm kế (next hop) phải được học từ IGP khi thực thi MPLS VPN chứ không phải quảng cáo từ tiến trình BGP. Nhãn VPN được mô tả bằng trường V1 và V2 trong hình trên
(4) Cập nhật MP-BGP được nhận bởi PE2 và tuyến được lưu trữ trong bảng VRF tương ứng cho Customer A dựa trên nhãn VPN
(5) Các tuyến MP-BGP nhận được được phân phối vào các tiến trình định tuyến VRF PE-CE, và tuyến được quảng bá tới CE2-A.
-Khi thực thi một MPLS VPN, mọi VPN site thuộc vào một khách hàng có thể liên lạc với mọi site trong cùng miền của khách hàng đó được gọi là VPN đơn giản hay intranet VPN. RT có thể được sử dụng để thực hiện cấu trúc VPN phức tạp, các site của một khách hàng có thể truy cập đến site của các khách hàng khác. Dạng thực thi này được gọi là extranet VPN. Các biến thể của extranet VPN như network management VPN, central services VPN và Internet access VPN có thể được triển khai.
2.2.5.Route Distinguisher
-Trong mô hình MPLS VPN, bộ định tuyến PE phân biệt các khách hàng bằng VRF. Tuy nhiên, thông tin này cần được mang theo giữa các bộ định tuyến PE để cho phép truyền dữ liệu giữa các site khách hàng qua MPLS VPN backbone. Bộ định tuyến PE phải có khả năng thực thi các tiến trình cho phép các mạng khách hàng kết nối vào có không gian địa chỉ trùng lắp (overlapping address spaces). Bộ định tuyến PE học các tuyến này từ các mạng khách hàng và quảng bá thông tin này bằng mạng trục chia sẻ của nhà cung cấp (shared provider backbone). Điều này thực hiện bằng việc kết hợp của sự khác biệt tuyến (RD – route distinguisher) trong bảng định tuyến ảo (virtual routing table) trên một bộ định tuyến PE.
-RD là một định danh 64-bit duy nhất, thêm vào trước 32-bit địa chỉ tuyến được học từ bộ định tuyến CE tạo thành địa chỉ 96-bit duy nhất có thể được chuyển vận giữa các bộ định tuyến PE trong miền MPLS. Do đó chỉ duy nhất một RD được cấu hình cho VRF trên bộ định tuyến PE. Địa chỉ 96-bit cuối cùng (tổng hợp của 32-bit địa chỉ khách hàng và 64-bit RD) được gọi là một địa chỉ VPNv4.
-Địa chỉ VPNv4 trao đổi giữa các bộ định tuyến PE trong mạng nhà cung cấp. Định dạng của RD có thể có hai định dạng: dạng địa chỉ IP hoặc chỉ số AS. Hình 2.6 cho thấy hai khách hàng có địa chỉ mạng giống nhau, 172.16.10.0/24, được phân biệt nhờ vào các giá trị RD khác nhau, 1:1 và 1:101, ưu tiên quảng bá địa chỉ VPNv4 trên bộ định tuyến PE.
H29.RD trong MPLS VPN
2.2.6.MP-BGP :
-Giao thức dùng để trao đổi các tuyến VPNv4 giữa các PE là multiprotocol BGP (MP-BGP). IGP yêu cầu duy trì iBGP (internal BGP) khi thực thi MPLS VPN. Do đó, PE phải chạy một IGP cung cấp thông tin NLRI cho iBGP nếu cả hai PE cùng trong một AS. Hiện tại, Cisco hỗ trợ cả OSPFv2 và ISIS trong mạng nhà cung cấp như là IGP. MP-BGP cũng chịu trách nhiệm chỉ định nhãn VPN. Khả năng mở rộng là lý do chính chọn BGP làm giao thức mang thông tin định tuyến khách hàng. Hơn nữa, BGP cho phép sử dụng địa chỉ VPNv4 trong môi trường MPLS VPN bộ định tuyến với dãy địa chỉ trùng lắp cho nhiều khách hàng.
-Một phiên làm việc MP-BGP (MP-BGP session) giữa các PE trong một BGP AS được gọi là phiên MP-iBGP (MP-iBGP session) và kèm theo các nguyên tắc thực thi của iBGP liên quan đến thuộc tính của BGP (BGP attributes). Nếu VPN mở rộng ra khỏi phạm vi một AS, các VPNv4 sẽ trao đổi giữa các AS tại biên bằng MP-eBGP session.
-Các thuộc tính commynity BGP mở rộng khác như SoO (site of origin) có thể dùng chủ yếu trong quảng bá cập nhật MP-iBGP. Thuộc tính SoO được dùng để xác định site cụ thể từ tuyến học được của PE và ứng dụng trong việc chống vòng lặp tuyến (routing loop) vì nó xác định được nguồn của site nên có thế ngăn việc quảng cáo lại mạng cho site đã gửi quảng cáo đó. SoO xác định duy nhất một site từ một tuyến mà PE học được. SoO cho phép lọc lưu lượng dựa trên site mà lưu lượng đó xuất phát. Khả năng lọc của SoO giúp quản trị lưu lượng MPLS VPN và chống vòng lặp tuyến xảy ra trong cấu trúc mạng hỗn hợp và phức tạp, các site khách hàng trong đó có thể xử lý các kết nối qua MPLS VPN backbone như các kết nối cửa sau (backdoor link) giữa các site.
2.2.7.Address Families:
-Address family là một khái niệm quan trọng trong hoạt động của MP-BGP cho phép chuyển vận các tuyến VPNv4 với các thuộc tính community mở rộng. Theo RFC 2283 “Multiprotocol Extensions for BGP-4”, BGPv4 chỉ có khả năng mang thông tin định tuyến thuộc vào Ipv4. BGP-4 có thể mang thông tin của nhiều giao thức lớp mạng. BGP-4 hỗ trợ định tuyến cho nhiều giao thức lớp mạng, BGP-4 phải đăng ký (account) một giao thức lớp mạng cụ thể liên quan đế một trạm kế (next hop) như NLRI (network layer reachability information). Hai thuộc tính mới được thêm vào của BGP là MP_REACH_NLRI (Multiprotocol Reachable NLRI ) và MP_UNREACH_NLRI (Multiprotocol Unreachable NLRI). MP_REACH_NLRI mang một tập các đích đến được (reachable destination) với thông tin trạm kế được dùng để chuyển tiếp cho các đích đến này. MP_UNEACH_NLRI mang một tập các đích không đến được. Cả hai thuộc tính này là optional và nontransitive. Vì thế, một BGP speaker không hỗ trợ tính năng đa giao thức này 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 các BGP speaker khác.
Một address family là một giao thức lớp mạng được định nghĩa. Một định danh họ địa chỉ (AFI – address family identifier) mang một định danh của giao thức lớp mạng kết hợp với địa chỉ mạng trong thuộc tính đa giao thức của BGP. AFI cho các giao thức lớp mạng được xác định trong RFC 1700, ‘Assigned Numbers’.
-PE thực chất là một LER biên (Edge LSR) và thực hiện tất cả chức năng của một Edge LSR. PE yêu cầu LDP cho việc gán và phân phối nhãn cũng như chuyển tiếp các gói được gắn nhãn. Cộng thêm các chức năng của một Edge LSR, PE thực thi một giao thức định tuyến (hay định tuyến tĩnh) vớ các EC trong một bảng định tuyến ảo (virtual routing table) và yêu cầu MP-BGP quảng bá các mạng học được từ CE như các VPNv4 trong MP-iBGP đến các PE khác bằng nhãn VPN.
-Bộ định tuyến P cần chạy một IGP (OSPF hoặc ISIS) khi MPLS cho phép chuyển tiếp các gói được gán nhãn (mặt phẳng dữ liệu – data plane) giữa các PE. IGP quảng bá các NLRI đến các P và PE để thực thi một MP—iBGP session giữa các PE (mặt phẳng điều khiển – control plane). LDP chạy trên các bộ định tuyến P để gán và phân phối nhãn.
2.2.8.Hoạt động của mặt phẳng điều khiển MPLS VPN
-Mặt phẳng điều khiển trong MPLS VPN chứa mọi thông tin định tuyến lớp 3 và các tiến trình trao đổi thông tin của các IP prefix được gán và phân phối nhãn bằng LDP. Mặt phẳng dữ liệu thực hiện chức năng chuyển tiếp các gói IP được gán nhãn đến trạm kế để về đích. Hình 2.8 cho thấy sự tương tác của các giao thức trong mặt phẳng điều khiển của MPLS VPN
H30.Sự tương tác trong mặt phẳng điều khiển của MPLS VPN
-Các bộ định tuyến CE được kết nối với các PE, và một IGP, BGP, hay tuyến tĩnh (static route) được yêu cầu trên các CE cùng với các PE để thu thập và quảng cáo thông tin NLRI. Trong MPLD VPN backbone gồm các bộ định tuyến P và PE, một IGP kết hợp với LDP được sử dụng giữa các PE và P. LDP dùng để phân phối nhãn trong một MPLS domain. IGP dùng để trao đổi thông tin NLRI, ánh xạ (map) các NLRI này vào MP-BGP. MP-BGP được duy trì giữa các PE trong một miền MPLS VPN và trao đổi cập nhật MP-BGP.
-Các gói từ CE đến PE luôn được quảng bá như các gói Ipv4. Hoạt động của mặt phẳng điều khiển MPLS VPN như hình sau :
H31.Hoạt động của mặt phẳng điều khiển
-Sau đây là các bước hoạt động của mặt phẳng điều khiển MPLS VPN (minh họa bằng hình trên):
(1) Cập nhật Ipv4 cho mạng 172.16.10.0 được nhận bởi egress PE (mặt phẳng dữ liệu).
(2) PE1-AS1 nhận và vận chuyển tuyến Ipv4, 172.16.10.0/24, đến một tuyến VPN4 gắn với RD 1:100, SoO, và RT 1:100 dựa trên cấu hình VRF trên PE1-AS1. Nó định vị một nhãn VPNv4 V1 tới cập nhật 172.16.10.0/24 và viết lại thuộc tính trạm kế cho địa chị 10.10.10.101 của loopback0 trên PE1-AS1. Hình 2.9 cho thất hoạt động của mặt phẳng điều khiển và việc quảng bá nhãn cho 10.10.10.101/32 từ PE1-AS1 tới PE2-AS2 trong mạng của nhà cung cấp. Sự quảng bá này nhanh chóng được thay thế ngay khi mạng MPLS VPN của nhà cung cấp được thiết lập và thực hiện quảng bá VPNv4 trong mạng. Các bước sau thực hiện tiến trình quảng bá nhãn cho 10.10.10.101/32:
2a: bộ định tuyến PE2-AS1 yêu cầu một nhãn cho 10.10.10.101/32 sử dụng LDP ánh xạ nhãn yêu cầu từ láng giềng xuôi dòng (downstream neighbor) của nó, P1-AS1. PE1-AS1 xác định một nhãn implicit-null cho 10.10.10.101/32, chỉnh sửa mục trong LFIB liên quan đến 10.10.10.101/32, và gửi đến P1-AS1 bằng LDP reply.
2b: P1-AS1 sử dụng nhãn implicit-null nhận được từ PE1-AS1 làm giá trị nhãn xuất (outbound label) của nó, các định một nhãn (L1) cho 10.10.10.101/32, và sửa mục trong LFIB cho 10.10.10.101/32. Sau đó P1-AS1 gửi giá trị nhãn này đến P2-AS1 bằng LDP reply.
2c: P2-AS1 dùng nhãn L1 làm giá trị nhãn xuất, xác định nhãn L2 cho 10.10.10.101/32, và sửa mục trong LFIB cho 10.10.10.101/32. Sau đó P2-AS2 gửi giá trị nhãn này đến PE2-AS1 bằng LDP reply.
PE1-AS1 có cấu hính VRF để nhân các tuyến với RT 1:100 nên chuyển cập nhật VPNv4 thành IPv4 và chèn tuyến trong VRF cho Customer A. Sau đó nó quảng bá tuyến này tới CE2-A.
Link bài trước:http://vnpro.org/forum/showthread.ph...-về-mpls-vpn
2.2.Hoạt động của kiến trúc MPLS/VPN:
2.2.1.Mô hình định tuyến MPLS/VPN:
-Giả sử chúng ta có 1 tình huống như thế này : Một nhà cung cấp dịch vụ SuperCom có 2 đại lý – 2 đại lý đó được đấu nối vào một core router.Mô hình như hình dưới:
H.20.Hình minh hoạ sơ đồ mạng
-Địa chỉ cho thành phần tương ứng của mô hình trên, các trụ sở chính dùng IP public các chi nhánh dùng IP Private:
H21.Bảng phân hoạch địa chỉ IP
-Lúc này ISP sẽ cung cấp dịch vụ IP-based VPN dựa trên mô hình mạng ngang hàng. Vấn đề bắt đầu từ đây, vì không gian địa chỉ của khách hàng kết nối vào cùng một router bị trùng. Thông thường các ISP sẽ có thể giải quyết vấn đề trên theo 3 cách sau: - ISP sẽ đàm phán để khách hàng điều chỉnh lại không gian mạng nội bộ của họ - nhưng hầu hết khách hàng sẽ ko làm điều này và sẽ tìm ISP khác.
- ISP có thể triển khai dịch VPN với những đường hầm IP-over-IP, IP của khách hàng sẽ được dấu từ nhà cung cấp dịch vụ.
- ISP sẽ triển khai một mạng NAT phức tạp – ISP sẽ chuyển đổi những địa chỉ của khách hàng sang một tập các địa chỉ khac(nhưng ko là duy nhất) tại router biên của ISP và sẽ chuyển đổi những địa chỉ đó trở lại địa chỉ của khách hàng lúc đầu trước khi gói tin được chuyển từ router biên của ISP sang CE. Giải pháp này khả thi nhưng chi phí cho công tác quản trị sẽ rất lớn.
-Vấn đề trùng địa chỉ trong ví dụ trên thường là kết quả từ việc sử dụng địa chỉ dành riêng trong mạng khách hàng, đây là một trong những trở ngại chính để triển khai mạng ngang hàng. Công nghệ MPLS/VPN cung cấp giải pháp khá tốt cho vấn đề nan giải này là : “Mỗi VPN sẽ có một bảng định tuyến và chuyển tiếp trên router – vì vậy mổi khách hàng hay mỗi site khách hàng thuộc VPN đó được cung cấp khả năng truy cập một tập các bảng định tuyến chứa trong bảng đó”. Các router PE trong mạng MPLS/VPN sẽ mang bảng định tuyến tương ứng mỗi VPN và bảng định tuyến ra ngoài internet – được dùng để tìm những router khác trong mạng nhà cung cấp hay các đích tới bên ngoài internet. Và kết quả thực tế là rất nhiều router ảo được tạo trong một router vật lý.
-Ý tưởng của việc tạo ra router ảo cho phép khách hàng có khả năng dùng địa chỉ dành riêng lẫn dùng chung trong mỗi VPN. Mổi site khách hàng thuộc cùng một VPN liên quan, vì vậy yêu cầu duy nhất cho ý tưởng này là không gian địa chỉ phải là duy nhất với VPN đó. Những địa chỉ duy nhất đó ko cần thiết giữa tất cả các VPN mà chỉ cần khi giữa 2 VPN có cùng không gian địa chỉ dùng riêng để giao tiếp
-Có nhiều cấu trúc liên quan tới mỗi router ảo hơn chỉ mỗi bảng định tuyến IP ảo :
- Một bảng chuyển tiếp được nhận từ bảng định tuyến và dựa trên công nghệ CEF.
- Một tập hợp các cổng dùng bảng chuyển tiếp trên.
- Có các luật dùng để điều khiển việc nhập hay xuất thông tin định tuyền từ bảng định tuyến VPN. Những luật đó được giới thiệu để hỗ trợ các overlapping VPN.
- Một tập hợp các giao thức dùng để gán thông tin vào bảng định tuyến VPN nó bao gồm cả định tuyến tĩnh.
- Nhửng router hay thay đổi đã liên kết với giao thức định tuyến được dùng để lan truyền bảng định tuyến VPN
H.22.Các router ảo được tạo trong PE router
2.2.2.VRF- Virtual Routing and Forwarding Table
-Khách hàng được phân biệt trên router PE bằng các bảng định tuyến ảo (virtual routing tables) hoặc các instance, còn được gọi là VRF (Virtual Routing and Forwarding table/instances). Thực chất nó giống như duy trì nhiều router riêng biệt cho các khách hàng kết nối vào mạng của nhà cung cấp. Chức năng của VRF giống như một bảng tin định tuyến toàn cục, ngoại trừ việc nó chứa mọi tuyến liên quan đến một VPN cụ thể. VRF cũng chứa một bảng chuyển tiếp CEF cho VRF riêng biệt (VRF-specific CEF forwarding table) tương ứng với bản CEF toàn cục xác định các yêu cầu kết nối và các giao thức cho mỗi site khách hàng kết nối trên một router PE. VRF xác định giao thức định tuyến tham gia vào một VPN cụ thể cũng như giao tiếp trên router PE cục bộ tham gia vào VPN. Giao tiếp tham gia vào VRF phải hỗ trợ chuyển mạch CEF. Một VRF có thể gồm một giao tiếp (logical hay physical) hoặc nhiều giao tiếp trên một router.
-VRF chứa một bảng định tuyến IP tương ứng với bảng định tuyến IP toàn cục, một bảng CEF, liệt kê các giao tiếp tham gia vào VRF, và một tập hợp các nguyên tắc xác định giao thức định tuyến trao đổi với các router CE (routing protocol contexts). VRF còn chứa các định danh VPN (VPN identifier) như thông tin thành viên VPN (RD và RT). Hình sau cho thấy chức năng của VRF trên một router PE thực hiện tách tuyến khách hàng.
H.23. VRF tách tuyến khách hàng
-Hiện tại, Cisco IOS hỗ trợ RIPv2, EIGRP, BGPv4 (nhiều instance), và OSPFv2 (nhiều tiến trình) được dùng cho VRF để trao đổi thông tin định tuyến giữa CE và PE. Chú ý rằng: các giao tiếp VRF có thể là luận lý (logical) hoặc vật lí (physical) nhưng mỗi giao tiếp chỉ được gán với một VRF.
Cấu hình VRF cơ bản:
-Khi cấu hình VRF là ISP cấu hình cho khách hàng của họ có thể nhận route từ các PE. ISP đính kèm VRF trên mổi PE trong đường trục MPLS/VPN để các site có thể nhận route từ VPN của mình vì vậy các tất cả PE phải có các cấu hình VRF liên quan cho VPN tương ứng
-Lệnh được sử dụng trong mode config – cú pháp : ip vrf [vrfname] trong đó [vrfname] tên site ta muốn truyền route
R1(config)#ip vrf FastFood
R1(config-vrf)#
2.2.3.Overlapping VPN:
-Trong ví dụ trên dường như làm cho ta tin rằng một VPN được liên kết với một VRF đơn trong PE. Điều đó sẽ đúng trong trường hợp VPN của khách hàng ko kết nối với 1 khách hàng khác – Chính vấn đề nảy sinh này làm cho nó trở nên phức tạp hơn và yêu cầu phải nhiều hơn VRF trên mỗi VPN khách hàng.
-Tưởng tượng rằng ISP trong ví dụ trên muốn mở rộng dịch vụ của họ và cung cấp VoIP với cổng kết nối ra những mạng voice công cộng. Cổng kết nối của VoIP được đặt trong những VPN tách biệt để tăng độ bảo mật của dịch vụ này
H24.Mô hình Voice Gateway
H25.IP voice tương ứng
H26.Mô hình VPN chồng lên nhau
-Ý tưởng VRF phải được sửa đổi lại để hỗ trợ khái niệm “sites” – một khái niệm ko dừng lại VPN đơn mà là đa VPN. Ta lấy ví dụ như mô hình trên , không thể nào 2 hội sở FastFood và EuroBank lại có cùng VRF như tất cả các site con của mình khi kết nối vào cùng PE. Cụ thể hơn , ta thấy hội sở EuroBank cần phải truy xuất được VoIP gateway vì vậy các định tuyến tới gateways đó phải có trong VRF cho site hội sở chính trong khi VRF của site Chartres sẽ ko có các route đó. Vì vậy kiến trúc MPLS phân loại ý tưởng VRF lẻ từ khái niệm VPN
Mối quan hệ giửa các VPN, site , VRF có thể summarized theo quy tắc sau:
H27.Bảng Sumary của VRF
-Route targets (RTs) là những định danh dùng trong MPLS VPN domain khi triển khai MPLS VPN nhằm xác định thành viên VPN của các tuyến được học từ các site cụ thể. RT được thực thi bởi các BGP community mở rộng sử dụng 16 bit cao của BGP ecxtended community (64 bit) mã hóa với một gí trị tương ứng với thành viên VPN của site cụ thể. Khi một tuyến VPN học từ một CE chèn vào VPNv4 BGP, một danh sách các thuộc tính community mở rộng cho VPN router target được kết hợp với nó. Export RT dùng để xác định thành viên VPN và được kết lớp với mỗi VRF. Export RT được nối thêm vào địa chỉ khách hàng (customer prefix) khi chuyển thành địa chỉ VPNv4 bởi PE và quảng bá trong các cập nhật MP-BGP. Import RT kết hợp với mỗi VRF và xác định các tuyến VPNv4 được thêm vào VRF cho khách hàng cụ thể. Định dạng của RT giống như giá trị RD. Sự tương tác của RT và giá trị RD trong MPLS VPN domain khi cập nhật được chuyển thành cập nhật MP-BGP
H28.Hình cập nhật MP-BGP
-Các tiến trình sau xảy ra trong suốt quá trình quảng bá tuyến trong một MPLS VPN như hình trên:
(1) Mạng 172.16.10.0/24 được nhận từ CE1-A, tham gia vào VRF CustomerA trên PE1-AS1.
(2) PE1 kết hợp một giá trị RD 1:100 và một giá trị export RT 1:100 khi cấu hình cho VRF trên bộ định tuyến PE1-AS1.
(3) Các tuyến học từ CE1-A được phân phối vào tiến trình MP-BGP trên PE1-AS1 với prefix 172.16.10.0/24 và thêm vào đầu giá trị RD 1:100 và nối thêm export RT 1:100 để gửi đi địa chỉ VPNv4 khi tham gia cập nhật MP-iBGP giữa các PE.
-Nhãn VPN (3 byte) được gán cho mỗi địa chỉ học từ các tiến trình của CE kết nối trong một VRF từ tiến trình MP-BGP của PE. MP-BGP chạy trong miền MPLS của nhà cung cấp dịch vụ nên mang theo địa chỉ VPNv4 (Ipv4 + RD) và BGP RT.
Lưu ý: mặc dù RT là cấu hình bắc buộc trong một MPLS VPN cho mọi VRF trên một bộ định tuyến, giá trị RT có thể được dùng để thực thi trên cấu trúc mạng VPN phức tạp, trong đó một site có thể tham gia vào nhiều VPN. Giá trị RT còn có thể dùng để chọn tuyến nhập vào VRF khi các tuyến VPnv4 được học trong các cập nhật MP-iBGP. Nhãn VPN chỉ được hiểu bởi egress PE (mặt phẳng dữ liệu) kết nối trực tiếp với CE quảng cáo mạng đó. Các trạm kế (next hop) phải được học từ IGP khi thực thi MPLS VPN chứ không phải quảng cáo từ tiến trình BGP. Nhãn VPN được mô tả bằng trường V1 và V2 trong hình trên
(4) Cập nhật MP-BGP được nhận bởi PE2 và tuyến được lưu trữ trong bảng VRF tương ứng cho Customer A dựa trên nhãn VPN
(5) Các tuyến MP-BGP nhận được được phân phối vào các tiến trình định tuyến VRF PE-CE, và tuyến được quảng bá tới CE2-A.
-Khi thực thi một MPLS VPN, mọi VPN site thuộc vào một khách hàng có thể liên lạc với mọi site trong cùng miền của khách hàng đó được gọi là VPN đơn giản hay intranet VPN. RT có thể được sử dụng để thực hiện cấu trúc VPN phức tạp, các site của một khách hàng có thể truy cập đến site của các khách hàng khác. Dạng thực thi này được gọi là extranet VPN. Các biến thể của extranet VPN như network management VPN, central services VPN và Internet access VPN có thể được triển khai.
2.2.5.Route Distinguisher
-Trong mô hình MPLS VPN, bộ định tuyến PE phân biệt các khách hàng bằng VRF. Tuy nhiên, thông tin này cần được mang theo giữa các bộ định tuyến PE để cho phép truyền dữ liệu giữa các site khách hàng qua MPLS VPN backbone. Bộ định tuyến PE phải có khả năng thực thi các tiến trình cho phép các mạng khách hàng kết nối vào có không gian địa chỉ trùng lắp (overlapping address spaces). Bộ định tuyến PE học các tuyến này từ các mạng khách hàng và quảng bá thông tin này bằng mạng trục chia sẻ của nhà cung cấp (shared provider backbone). Điều này thực hiện bằng việc kết hợp của sự khác biệt tuyến (RD – route distinguisher) trong bảng định tuyến ảo (virtual routing table) trên một bộ định tuyến PE.
-RD là một định danh 64-bit duy nhất, thêm vào trước 32-bit địa chỉ tuyến được học từ bộ định tuyến CE tạo thành địa chỉ 96-bit duy nhất có thể được chuyển vận giữa các bộ định tuyến PE trong miền MPLS. Do đó chỉ duy nhất một RD được cấu hình cho VRF trên bộ định tuyến PE. Địa chỉ 96-bit cuối cùng (tổng hợp của 32-bit địa chỉ khách hàng và 64-bit RD) được gọi là một địa chỉ VPNv4.
-Địa chỉ VPNv4 trao đổi giữa các bộ định tuyến PE trong mạng nhà cung cấp. Định dạng của RD có thể có hai định dạng: dạng địa chỉ IP hoặc chỉ số AS. Hình 2.6 cho thấy hai khách hàng có địa chỉ mạng giống nhau, 172.16.10.0/24, được phân biệt nhờ vào các giá trị RD khác nhau, 1:1 và 1:101, ưu tiên quảng bá địa chỉ VPNv4 trên bộ định tuyến PE.
H29.RD trong MPLS VPN
2.2.6.MP-BGP :
-Giao thức dùng để trao đổi các tuyến VPNv4 giữa các PE là multiprotocol BGP (MP-BGP). IGP yêu cầu duy trì iBGP (internal BGP) khi thực thi MPLS VPN. Do đó, PE phải chạy một IGP cung cấp thông tin NLRI cho iBGP nếu cả hai PE cùng trong một AS. Hiện tại, Cisco hỗ trợ cả OSPFv2 và ISIS trong mạng nhà cung cấp như là IGP. MP-BGP cũng chịu trách nhiệm chỉ định nhãn VPN. Khả năng mở rộng là lý do chính chọn BGP làm giao thức mang thông tin định tuyến khách hàng. Hơn nữa, BGP cho phép sử dụng địa chỉ VPNv4 trong môi trường MPLS VPN bộ định tuyến với dãy địa chỉ trùng lắp cho nhiều khách hàng.
-Một phiên làm việc MP-BGP (MP-BGP session) giữa các PE trong một BGP AS được gọi là phiên MP-iBGP (MP-iBGP session) và kèm theo các nguyên tắc thực thi của iBGP liên quan đến thuộc tính của BGP (BGP attributes). Nếu VPN mở rộng ra khỏi phạm vi một AS, các VPNv4 sẽ trao đổi giữa các AS tại biên bằng MP-eBGP session.
-Các thuộc tính commynity BGP mở rộng khác như SoO (site of origin) có thể dùng chủ yếu trong quảng bá cập nhật MP-iBGP. Thuộc tính SoO được dùng để xác định site cụ thể từ tuyến học được của PE và ứng dụng trong việc chống vòng lặp tuyến (routing loop) vì nó xác định được nguồn của site nên có thế ngăn việc quảng cáo lại mạng cho site đã gửi quảng cáo đó. SoO xác định duy nhất một site từ một tuyến mà PE học được. SoO cho phép lọc lưu lượng dựa trên site mà lưu lượng đó xuất phát. Khả năng lọc của SoO giúp quản trị lưu lượng MPLS VPN và chống vòng lặp tuyến xảy ra trong cấu trúc mạng hỗn hợp và phức tạp, các site khách hàng trong đó có thể xử lý các kết nối qua MPLS VPN backbone như các kết nối cửa sau (backdoor link) giữa các site.
2.2.7.Address Families:
-Address family là một khái niệm quan trọng trong hoạt động của MP-BGP cho phép chuyển vận các tuyến VPNv4 với các thuộc tính community mở rộng. Theo RFC 2283 “Multiprotocol Extensions for BGP-4”, BGPv4 chỉ có khả năng mang thông tin định tuyến thuộc vào Ipv4. BGP-4 có thể mang thông tin của nhiều giao thức lớp mạng. BGP-4 hỗ trợ định tuyến cho nhiều giao thức lớp mạng, BGP-4 phải đăng ký (account) một giao thức lớp mạng cụ thể liên quan đế một trạm kế (next hop) như NLRI (network layer reachability information). Hai thuộc tính mới được thêm vào của BGP là MP_REACH_NLRI (Multiprotocol Reachable NLRI ) và MP_UNREACH_NLRI (Multiprotocol Unreachable NLRI). MP_REACH_NLRI mang một tập các đích đến được (reachable destination) với thông tin trạm kế được dùng để chuyển tiếp cho các đích đến này. MP_UNEACH_NLRI mang một tập các đích không đến được. Cả hai thuộc tính này là optional và nontransitive. Vì thế, một BGP speaker không hỗ trợ tính năng đa giao thức này 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 các BGP speaker khác.
Một address family là một giao thức lớp mạng được định nghĩa. Một định danh họ địa chỉ (AFI – address family identifier) mang một định danh của giao thức lớp mạng kết hợp với địa chỉ mạng trong thuộc tính đa giao thức của BGP. AFI cho các giao thức lớp mạng được xác định trong RFC 1700, ‘Assigned Numbers’.
-PE thực chất là một LER biên (Edge LSR) và thực hiện tất cả chức năng của một Edge LSR. PE yêu cầu LDP cho việc gán và phân phối nhãn cũng như chuyển tiếp các gói được gắn nhãn. Cộng thêm các chức năng của một Edge LSR, PE thực thi một giao thức định tuyến (hay định tuyến tĩnh) vớ các EC trong một bảng định tuyến ảo (virtual routing table) và yêu cầu MP-BGP quảng bá các mạng học được từ CE như các VPNv4 trong MP-iBGP đến các PE khác bằng nhãn VPN.
-Bộ định tuyến P cần chạy một IGP (OSPF hoặc ISIS) khi MPLS cho phép chuyển tiếp các gói được gán nhãn (mặt phẳng dữ liệu – data plane) giữa các PE. IGP quảng bá các NLRI đến các P và PE để thực thi một MP—iBGP session giữa các PE (mặt phẳng điều khiển – control plane). LDP chạy trên các bộ định tuyến P để gán và phân phối nhãn.
2.2.8.Hoạt động của mặt phẳng điều khiển MPLS VPN
-Mặt phẳng điều khiển trong MPLS VPN chứa mọi thông tin định tuyến lớp 3 và các tiến trình trao đổi thông tin của các IP prefix được gán và phân phối nhãn bằng LDP. Mặt phẳng dữ liệu thực hiện chức năng chuyển tiếp các gói IP được gán nhãn đến trạm kế để về đích. Hình 2.8 cho thấy sự tương tác của các giao thức trong mặt phẳng điều khiển của MPLS VPN
H30.Sự tương tác trong mặt phẳng điều khiển của MPLS VPN
-Các bộ định tuyến CE được kết nối với các PE, và một IGP, BGP, hay tuyến tĩnh (static route) được yêu cầu trên các CE cùng với các PE để thu thập và quảng cáo thông tin NLRI. Trong MPLD VPN backbone gồm các bộ định tuyến P và PE, một IGP kết hợp với LDP được sử dụng giữa các PE và P. LDP dùng để phân phối nhãn trong một MPLS domain. IGP dùng để trao đổi thông tin NLRI, ánh xạ (map) các NLRI này vào MP-BGP. MP-BGP được duy trì giữa các PE trong một miền MPLS VPN và trao đổi cập nhật MP-BGP.
-Các gói từ CE đến PE luôn được quảng bá như các gói Ipv4. Hoạt động của mặt phẳng điều khiển MPLS VPN như hình sau :
H31.Hoạt động của mặt phẳng điều khiển
(1) Cập nhật Ipv4 cho mạng 172.16.10.0 được nhận bởi egress PE (mặt phẳng dữ liệu).
(2) PE1-AS1 nhận và vận chuyển tuyến Ipv4, 172.16.10.0/24, đến một tuyến VPN4 gắn với RD 1:100, SoO, và RT 1:100 dựa trên cấu hình VRF trên PE1-AS1. Nó định vị một nhãn VPNv4 V1 tới cập nhật 172.16.10.0/24 và viết lại thuộc tính trạm kế cho địa chị 10.10.10.101 của loopback0 trên PE1-AS1. Hình 2.9 cho thất hoạt động của mặt phẳng điều khiển và việc quảng bá nhãn cho 10.10.10.101/32 từ PE1-AS1 tới PE2-AS2 trong mạng của nhà cung cấp. Sự quảng bá này nhanh chóng được thay thế ngay khi mạng MPLS VPN của nhà cung cấp được thiết lập và thực hiện quảng bá VPNv4 trong mạng. Các bước sau thực hiện tiến trình quảng bá nhãn cho 10.10.10.101/32:
2a: bộ định tuyến PE2-AS1 yêu cầu một nhãn cho 10.10.10.101/32 sử dụng LDP ánh xạ nhãn yêu cầu từ láng giềng xuôi dòng (downstream neighbor) của nó, P1-AS1. PE1-AS1 xác định một nhãn implicit-null cho 10.10.10.101/32, chỉnh sửa mục trong LFIB liên quan đến 10.10.10.101/32, và gửi đến P1-AS1 bằng LDP reply.
2b: P1-AS1 sử dụng nhãn implicit-null nhận được từ PE1-AS1 làm giá trị nhãn xuất (outbound label) của nó, các định một nhãn (L1) cho 10.10.10.101/32, và sửa mục trong LFIB cho 10.10.10.101/32. Sau đó P1-AS1 gửi giá trị nhãn này đến P2-AS1 bằng LDP reply.
2c: P2-AS1 dùng nhãn L1 làm giá trị nhãn xuất, xác định nhãn L2 cho 10.10.10.101/32, và sửa mục trong LFIB cho 10.10.10.101/32. Sau đó P2-AS2 gửi giá trị nhãn này đến PE2-AS1 bằng LDP reply.
PE1-AS1 có cấu hính VRF để nhân các tuyến với RT 1:100 nên chuyển cập nhật VPNv4 thành IPv4 và chèn tuyến trong VRF cho Customer A. Sau đó nó quảng bá tuyến này tới CE2-A.