MPLS

VnPro – Cisco Authorized Training Center

Trần Thị Tố Uyên 1

CHUYỂN MẠCH NHÃN ĐA GIAO TH ỨC

(MPLS MultiProtocol Label Switching)

Tác giả: Tr ần Thị Tố Uyên



Mục lục

Chương 1: TỔNG QUAN VỀ MPLS ........................................................................ 3 Chương 2: CẤU HÌNH MPLS CƠ BẢN ................................................................. 13

LAB 2-1: Cấu hình MPLS frame-mode cơ bản.................................................... 16 Chương 3: TỔNG QUAN VỀ MPLS VPN.............................................................. 28 Chương 4: GIAO THỨC ĐỊNH TUYẾN EIGRP PE-CE......................................... 43

LAB 4-1: Cấu hình định tuyến EIGRP PE-CE cơ bản.......................................... 46 LAB 4-2: Cấu hình mạng sử dụng BGP CC và EIGRP SoO ................................ 62

Chương 5: GIAO THỨC ĐỊNH TUYẾN OSPF PE-CE........................................... 75 LAB 5-1 – Cấu hình định tuyến OSPF PE-CE ..................................................... 86 LAB 5-2—OSPF Sham-Links ............................................................................101

Chương 6: KỸ THUẬT LƯU LƯỢNG TRONG MPLS.........................................112



Chương 1: TỔNG QUAN VỀ MPLS

Giới thi ệu về chuyển mạch nhãn đa giao thức (MPLS):

MPLS là một công nghệ kết hợp đặc điểm tốt nhất giữa định tuyến lớp ba và chuyển mạch lớp hai cho phép chuyển tải các gói rất nhanh trong mạng lõi (core) và định tuyến tốt ở mạng biên (edge) bằng cách dựa vào nhãn (label). MPLS là một phương pháp cải tiến việc chuyển tiếp gói trên mạng bằng các nhãn được gắn với mỗi gói IP, tế bào ATM, hoặc frame lớp hai. Phương pháp chuyển mạch nhãn giúp các Router và MPLS-enable ATM switch ra quyết định theo nội dung nhãn tốt hơn việc định tuyến phức tạp theo địa chỉ IP đích. MPLS kết nối tính thực thi và khả năng chuyển mạch lớp hai với định tuyến lớp ba. Cho phép các ISP cung cấp nhiều dịch vụ khác nhau mà không cần phải bỏ đi cơ sở hạ tầng sẵn có. Cấu trúc MPLS có tính mềm dẻo trong bất kỳ sự phối hợp với công nghệ lớp hai nào. MPLS hỗ trợ mọi giao thức lớp hai, triển khai hiệu quả các dịch cụ IP trên một mạng chuyển mạch IP. MPLS hỗ trợ việc tạo ra các tuyến khác nhau giữa nguồn và đích trên một đường trục Internet. Bằng việc tích hợp MPLS vào kiến trúc mạng, Các ISP có thể giảm chi phí, tăng lợi nhuận, cung cấp nhiều hiệu quả khác nhau và đạt được hiệu quả cạnh tranh cao.

Đặc điểm mạng MPLS: - Không có MPLS API, cũng không có thành phần giao thức phía host. - MPLS chỉ nằm trên các router. - MPLS là giao thức độc lập nên có thể hoạt động cùng với giao thức khác IP

như IPX, ATM, Frame Relay,… - MPLS giúp đơn giản hoá quá trình định tuyến và làm tăng tính linh động của

các tầng trung gian.

Phương thức hoạt động: Thay thế cơ chế định tuyến lớp ba bằng cơ chế chuyển mạch lớp hai. MPLS hoạt động trong lõi của mạng IP. Các Router trong lõi phải enable MPLS trên từng giao tiếp. Nhãn được gắn thêm vào gói IP khi gói đi vào mạng MPLS. Nhãn được tách ra khi gói ra khỏi mạng MPLS. Nhãn (Label) được chèn vào giữa header lớp ba và header lớp hai. Sử dụng nhãn trong quá trình gửi gói sau khi đã thiết lập đường đi. MPLS tập trung vào quá trình hoán đổi nhãn (Label Swapping). Một trong những thế mạnh của khiến trúc MPLS là tự định nghĩa chồng nhãn (Label Stack).

Công thức để gán nhãn gói tin là:

Network Layer Packet + MPLS Label Stack

Không gian nhãn (Label Space): có hai loại. Một là, các giao tiếp dùng chung giá trị nhãn (per-platform label space). Hai là, mỗi giao tiếp mang giá trị nhãn riêng, (Per-interface Label Space).

Bộ định tuyến chuyển nhãn (LSR – Label Switch Router): ra quyết định chặng kế tiếp dựa trên nội dung của nhãn, các LSP làm việc ít và hoạt động gần giống như Switch.

Con đường chuyển nhãn (LSP – Label Switch Path): xác định đường đi của gói tin MPLS. Gồm hai loại: Hop by hop signal LSP - xác định đường đi khả thi nhất theo kiểu best effort và Explicit route signal LSP - xác định đường đi từ nút gốc.

Một số ứng dụng của MPLS



Internet có ba nhóm ứng dụng chính: voice, data, video với các yêu cầu khác nhau. Voice yêu cầu độ trễ thấp, cho phép thất thoát dữ liệu để tăng hiếu quả. Video cho phép thất thoát dữ liệu ở mức chấp nhận được, mang tính thời gian thực (realtime). Data yêu cầu độ bảo mật và chính xác cao. MPLS giúp khai thác tài nguyên mạng đạt hiệu quả cao.

Một số ứng dụng đang được triển khai là: MPLS VPN: Nhà cung cấp dịch cụ có thể tạo VPN lớp 3 dọc theo mạng đường trục cho nhiều khách hàng, chỉ dùng một cơ sở hạ tầng công cộng sẵn có, không cần các ứng dụng encrytion hoặc end-user. MPLS Traggic Engineer: Cung cấp khả năng thiết lập một hoặc nhiều đường đi để điều khiển lưu lượng mạng và các đặc trưng thực thi cho một loại lưu lượng. MPLS QoS (Quality of service): Dùng QoS các nhà cung cấp dịch vụ có thể cung cấp nhiều loại dịch vụ với sự đảm bảo tối đa về QoS cho khách hàng. MPLS Unicast/Multicast IP routing. …

Điểm vượt tr ội của MPLS so với mô hình IP over ATM

Khi hợp nhất với chuyển mạch ATM, chuyển mạch nhãn tận dụng những thuận lợi của các tế bào ATM - chiều dài thích hợp và chuyển với tốc độ cao. Trong mạng đa dịch vụ chuyển mạch nhãn cho phép chuyển mạch BPX/MGX nhằm cung cấp dịch vụ ATM, Frame, Replay và IP Internet trên một mặt phẳng đơn trong một đường đi tốc độ cao. Các mặt phẳng (Platform) công cộng hỗ trợ các dịch vụ này để tiết kiệm chi phí và đơn giản hóa hoạt động cho nhà cung cấp đa dịch vụ. ISP sử dụng chuyển mạch ATM trong mạng lõi, chuyển mạch nhãn giúp các các dòng Cisco, BPX8600, MGX8800, Router chuyển mạch đa dịch vụ 8540 và các chuyển mạch Cisco ATM giúp quản lí mạng hiệu quả hơn xếp chồng (overlay) lớp IP trên mạng ATM. Chuyển mạch nhãn tránh những rắc rối gây ra do có nhiều router ngang hàng và hỗ trợ cấu trúc phân cấp (hierarchical structure) trong một mạng của ISP.

Sự tích hợp: MPLS xác nhập tính năng của IP và ATM chứ không xếp chồng lớp IP trên ATM. MPLS giúp cho cơ sở hạ tầng ATM thấy được định tuyến IP và loại bỏ các yêu cầu ánh xạ giữa các đặc tính IP và ATM. MPLS không cần địa chỉ ATM và kỹ thuật định tuyến (như PNNI).

Độ tin cậy cao hơn: Với cơ sở hạ tầng ATM, MPLS có thể kết hợp hiệu quả với nhiều giao thức định tuyến IP over ATM thiết lập một mạng lưới (mesh) dịch vụ công cộng giữ các router xung quanh một đám mây ATM. Tuy nhiên có nhiều vấn đề xảy ra do các PCV link giữa các router xếp chồng trên mạng ATM. Cấu trúc mạng ATM không thể thấy bộ định tuyến. Một link ATM bị hỏng làm hỏng nhiều router-to-router link, gây khó khăn cho lượng cập nhật thông tin định tuyến và nhiều tiến trình xử lí kéo theo.

Trực tiếp thực thi các loại dịch vụ: MPLS sử dụng hàng đợi và bộ đếm của ATM để cung cấp nhiều loại dịch vụ khác nhau. Nó hỗ trợ quyền ưu tiên IP và loại dịch vụ (class of service – cos) trên chuyển mạch ATM mà không cần chuyển đổi phức tạp sang các lớp ATM Forum Service.

Hỗ trợ hiệu quả cho Mulicast và RSVP: Khác với MPLS, xếp lớp IP trên ATM nảy sinh nhiều bất lợi, đặc biệt trong việc hỗ trợ các dịch vụ IP như IP muticast và RSVP( Resource Reservation Protocol - RSVP).



MPLS hỗ trợ các dịch vụ này, kế thừa thời gian và công việc theo các chuẩn và khuyến khích tạo nên ánh xạ xấp xỉ của các đặc trưng IP&ATM

Sự đo lường và quản lí VPN: MPLS có thể tính được các dịch vụ IP VPN và rất dễ quản lí các dịch vụ VPN quan trọng để cung cấp các mạng IP riêng trong cơ sở hạ tầng của nó. Khi một ISP cung cấp dịch vụ VPN hỗ trợ nhiều VPN riêng trên một cơ sở hạ tầng đơn.Với một đường trục MPLS, thông tin VPN chỉ được xử lí tại một điểm ra vào. Các gói mang nhãn MPLS đi qua một đường trục và đến điểm ra đúng của nó. Kết hợp MPLS với MP-BGP (Mutiprotocol Broder Gateway Protocol) tạo ra các dịch vụ VNP dựa trên nền MPLS (MPLS-based VNP) dễ quản lí hơn với sự điều hành chuyển tiếp để quản lí phía VNP và các thành viên VNP, dịch vụ MPSL-based VNP còn có thể mở rộng để hỗ trợ hàng trăm nghìn VPN.

Giảm tải trên mạng lõi Các dịch vụ VPN hướng dẫn cách MPLS hỗ trợ mọi thông tin định tuyến để phân cấp. Hơn nữa,có thể tách rời các định tuyến Internet khỏi lõi mạng cung cấp dịch vụ. Giống như dữ liệu VPN, MPSL chỉ cho phép truy suất bảng định tuyến Internet tại điểm ra vào của mạng. Với MPSL, kĩ thuật lưu lượng truyền ở biên của AS được gắn nhãn để liên kết với điểm tương ứng. Sự tách rời của định tuyến nội khỏi định tuyến Internet đầy đủ cũng giúp hạn chế lỗi, ổn định và tăng tính bảo mật Khả năng điều khiển lưu lượng: MPLS cung cấp các khả năng điều khiển lưu lượng để sửng dụng hiệu quả tài nguyên mạng. Kỹ thuật lưu lượng giúp chuyển tải từ các phần quá tải sang các phần còn rỗi của mạng dựa vào điểm đích, loại lưu lượng, tải, thời gian,…

Các hình thức hoạt động của MPLS

Mạng MPLS dùng các nhãn để chuyển tiếp các gói. Khi một gói đi vào mạng, Node MPLS ở lối vào đánh dấu một gói đến lớp chuyển tiếp tương đương (FEC – Forwarding Equivalence Class) cụ thể. Trong mạng MPLS nhãn điều khiển mọi hoạt động chuyển tiếp. Điều này có nhiều thuận lợi hơn sự chuyển tiếp thông thường: - Sự chuyển tiếp MPLS có thể thực hiện bằng các bộ chuyển mạch (switch), có thể

tra cứu (lookup) thay thế nhãn mà không ảnh hưởng đến header lớp mạng. Các bộ chuyển ATM thực hiệc các chức năng chuyển các tế bào dựa trên giá trị nhãn. ATM-switch cần được điều khiển bởi một thành phần điều khiển MPLS dựa vào IP (IP-base MPLS control element) như bộ điều khiển chuyển mạch nhãn (LSC - Label Switch Controller). Đây là dạng cơ bản của sự kết hợp IP với ATM.

- Khi một gói vào mạng nó được chuyển đến lớp chuyển tiếp tương đương (FEC - Forwarding Equivalence Class). Router có thể sử dụng thông tin gói, như cổng vào (ingress) hay giao tiếp (interface). Các gói đi vào mạng được gán các nhãn khác nhau. Quyết định chuyển tiếp được thực hiện dễ dàng bởi router ngõ vào. Điều này không có trong sự chuyển tiếp thông thường, vì sự xác định lộ trình của router khác với thông tin lộ trình trên gói.

- Mạng được quản lý lưu lượng buộc gói đi theo một con đường cụ thể, một con đường chưa được sử dụng. Con đường đó được chọn trước hoặc ngay khi gói đi vào mạng tốt hơn sự lựa chọn bởi các thuật toán định tuyến thông thường. Trong MPLS, một nhãn có thể được dùng để đại diện cho tuyến, không cần kèm trong gói. Đây là dạng cơ bản của MPLS Traffic Engineering.



- "Lớp dịch vụ (Class of service)" của gói được xác định bởi nút MPLS vào (ingress MPLS node). Một nút MPLS vào có thể huỷ tuyến hay sửa đổi l ịch trình để điều khiển các gói khác nhau. Các trạm sau có thể định lại ràng buộc dịch vụ bằng cách thiết lập PBH (per-hop behavior). MPLS cho phép (không yêu cầu) độ ưu tiên một phần hoặc hoàn toàn của lớp dịch vụ từ nhãn. Trường lợp này nhãn đại diện cho sự kết hợp của một FEC với độ ưu tiên hoặc lớp dịch vụ. Đây là dạng cơ bản của MPLS QoS.

Nhãn (Label) trong MPLS

Kiểu khung (Frame mode): Kiểu khung là thuật ngữ khi chuyển tiếp một gói với nhãn gắn trước tiêu đề lớp ba. Một nhãn được mã hoá với 20bit, nghĩa là có thể có 220 giá trị khác nhau. Một gói có nhiều nhãn, gọi là chồng nhãn (label stack). Ở mỗi chặng trong mạng chỉ có một nhãn bên ngoài được xem xét. Hình 2 mô tả định dạng tiêu đề của MPLS

Trong đó: - EXP=Experimental (3 bit): dành cho thực nghiệm. Cisco IOS sử dụng các bit này để giữ các thông báo cho QoS; khi các gói MPLS xếp hàng có thể dùng các bit

EXP tương tự như các bit IP ưu tiên (IP Precedence). - S=Bottom of stack (1 bit): là bít cuối chồng. Nhãn cuối chồng bit này được thiết

lập lên 1, các nhãn khác có bít này là 0. - TTL=Time To Live (8 bit): thời gian sống là bản sao của IP TTL. Giá trị của nó

được giảm tại mỗi chặng để tránh lặp (giống như trong IP). Thường dùng khi người điều hành mạng muốn che dấu cấu hình mạng bên dưới khi tìm đường từ mạng bên ngoài.

Kiểu tế bào (Cell mode): Thuật ngữ này dùng khi có một mạng gồm các ATM LSR dùng MPLS trong mặt phẳng điều khiển để trao đổi thông tin VPI/VCI thay vì dùng báo hiệu ATM. Trong kiểu tế bào, nhãn là trường VPI/VCI của tế bào. Sau khi trao đổi nhãn trong mặt phẳng điều khiển, ở mặt phẳng chuyển tiếp, router ngõ vào (ingress router) phân tách gói thành các tế bào ATM, dùng giá trị VCI/CPI tương ứng đã trao đổi trong mặt phẳng điều khiển và truyền tế bào đi. Các ATM LSR ở phía trong hoạt động như chuyển mạch ATM – chúng chuyển tiếp một tế bào dựa trên VPI/VCI vào và thông tin cổng ra tương ứng. Cuối cùng, router ngõ ra (egress router) sắp xếp lại các tế bào thành một gói.



Trong đó: GFC (Generic Flow Control): Điều khiển luồng chung VPI (Virtual Path Identifier): nhận dạng đường ảo VCI (Virtual Channel Identifier): nhận dạng kênh ảo PT (Payload Type): Chỉ thị kiểu trường tin CLP (Cell Loss Priority): Chức năng chỉ thị ưu tiên huỷ bỏ tế bào HEC (Header error check): Kiểm tra lỗi tiêu đề. Cấu trúc nút của MPLS

Một nút của MPLS có hai mặt phẳng: mặt phẳng chuyển tiếp MPLS và mặt phẳng điều khiển MPLS. Nút MPLS có thể thực hiện định tuyến lớp ba hoặc chuyển mạch lớp hai. Kiến trúc cơ bản của một nút MPLS như sau:

Mặt phẳng chuyển tiếp (Forwarding plane)

Mặt phẳng chuyển tiếp sử dụng một cơ sở thông tin chuyển tiếp nhãn (LFIB - Label Forwarding Information Base) để chuyển tiếp các gói. Mỗi nút MPLS có hai bảng liên quan đến việc chuyển tiếp là: cơ sở thông tin nhãn (LIB - Label Information Base) và LFIB. LIB chứa tất cả các nhãn được nút MPLS cục bộ đánh dấu và ánh xạ của các

ATM Cell header GFC VPI PTVCI CLP HEC Header lớp 3 Dữ liệu

Nhãn

Gói qua SONET/SDH PPP Header Nhãn Header lớp 3 Dữ liệu

Ethernet Ethernet Header Nhãn Header lớp 3 Dữ liệu

Shim header

Chuyển đổi thông tin định tuyến

Mặt phẳng chuyển tiếp

Mặt phẳng điều khiển

Giao thức định tuyến IP

Giao thức phân phối nhãn

Bảng định tuyến IP (ECF FIB)

Cơ sở định tuyến chuyển tiếp nhãn (LFIB)

Các gói IP vừa đến

Các gói được gắn nhãn vừa đến

Chuyển đổi thông tin liên kết nhãn

Các gói IP ra

Các gói IP được gắn nhãn ra



nhãn này đến các nhãn được nhận từ láng giềng (MPLS neighbor) của nó. LFIB sử dụng một tập con các nhãn chứa trong LIB để thực hiện chuyển tiếp gói.

Mặt phẳng điều khiển (Control Plane)

Mặt phẳng điều khiển MPLS chịu trách nhiệm tạo ra và lưu trữ LFIB. Tất cả các nút MPLS phải chạy một giao thức định tuyến IP để trao đổi thông tin định tuyến đến các nút MPLS khác trong mạng. Các nút MPLS enable ATM sẽ dùng một bộ điều khiển nhãn (LSC – Label Switch Controller) như router 7200, 7500 hoặc dùng một mô đun xử lý tuyến (RMP – Route Processor Module) để tham gia xử lý định tuyến IP.

Các giao thức định tuyến Link-state như OSPF và IS-IS là các giao thức được chọn vì chúng cung cấp cho mỗi nút MPLS thông tin của toàn mạng. Trong các bộ định tuyến thông thường, bản định tuyến IP dùng để xây dựng bộ lưu trữ chuyển mạch nhanh (Fast switching cache) hoặc FIB (dùng bởi CEF - Cisco Express Forwarding). Tuy nhiên với MPLS, bản định tuyến IP cung cấp thông tin của mạng đích và subnet prefix. Các giao thức định tuyến link-state gửi thông tin định tuyến (flood) giữa một tập các router nối trực tiếp (adjacent), thông tin liên kết nhãn chỉ được phân phối giữa các router nối trực tiếp với nhau bằng cách dùng giao thức phân phối (LDP – Label Distribution Protocol) hoặc TDP (Cisco ‘s proproetary Tag Distribution protocol).

Các nhãn được trao đổi giữa các nút MPLS kế cận để xây dựng nên LFIB. MPLS dùng một mẫu chuyển tiếp dựa trên sự hoán đổi nhãn để kết nối với các mô đun điều khiển khác nhau. Mỗi mô đun điều khiển chịu trách nhiệm đánh dấu và phân phối một tập các nhãn cũng như lưu trữ các thông tin điều khiển có liên quan khác. Các giao thức cổng nội (IGP – Interior Gateway Potocols) được dùng để xác nhận khả năng đến được, sự liên kết, và ánh xạ giữa FEC và địa chỉ trạm kế (next-hop address).

Các mô đun điều khiển MPLS gồm: Định tuyến Unicast (Unicast Routing) Định tuyến Multicast (Multicast Routing) Kỹ thuật lưu lượng (Traffic engineering) Mạng riêng ảo (VPN – Virtual private Network) Chất lượng dịch vụ (QoS – Quality of service)

Các thành phần mặt phẳng dữ liệu và mặt phẳng điều khiển của MPLS

Mặt phẳng điều khiển một nút mạng

Điều khiển định tuyến MPLS IP

Điều khiển định tuyến MPLS Multicast IP

Điều khiển định tuyến MPLS/VPN

Điều khiển Lưu lượng (MPLS TE)

Chất lượng dịch vụ (QoS)

Mặt phẳng dữ liệu tại một nút mạng

Cơ sở thông tin chuyển tiếp nhãn LFIB



Cisco Express Forwarding (CEF) là nền tảng cho MPLS và hoạt động trên các router của Cisco. Do đó, CEF là điều kiện tiên quyết trong thực thi MPLS trên mọi thiết bị của Cisco ngoại trừ các ATM switch chỉ hỗ trợ chức năng của mặt phẳng chuyển tiếp dữ liệu. CEF là một cơ chế chuyển mạch thuộc sở hữu của Cisco nhằm làm tăng tính đơn giản và khả năng chuyển tiếp gói IP. CEF tránh việc viết lại overhead của cache trong môi trường lõi IP bằng cách sử dụng một cơ sở thông tin chuyển tiếp (FIB – Forwarding Information Base) để quyết định chuyển mạch. Nó phản ánh toàn bộ nội dung của bảng định tuyến IP (IP routing table), ánh xạ 1-1 giữa FIB và bảng định tuyến. Khi router sử dụng CEF, nó duy trì tối thiểu 1 FIB, chứa một ánh xạ các mạng đích trong bảng định tuyến với các trạm kế tiếp (next-hop adjacencies) tương ứng. FIB ở trong mặt phẳng dữ liệu, nơi router thực hiện cơ chế chuyển tiếp và xử lý các gói tin. Trên router còn duy trì hai cấu trúc khác là cơ sở thông tin nhãn (LIB – Label Information Base) và cơ sở thông tin chuyển tiếp nhãn (LFIB – Label Forwarding Information Base). Giao thức phân phối sử dụng giữa các láng giềng MPLS có nhiệm vụ tạo ra các chỉ mục (entry) trong hai bảng này. LIB thuộc mặt phẳng điều khiển và được giao thức phân phối nhãn sử dụng khi địa chỉ mạng đích trong bảng định tuyến được ánh xạ với nhãn nhận được từ router xuôi dòng. LFIB thuộc mặt phẳng dữ liệu và chứa nhãn cục bộ (local label) đến nhãn trạm kế ánh xạ với giao tiếp ngõ ra (outgoing interface), được dùng để chuyển tiếp các gói được gán nhãn. Như vậy, thông tin về các mạng đến được do các giao thức định tuyến cung cấp dùng để xây dựng bảng định tuyến (RIB - Routing Information Base). RIB cung cấp thông tin cho FIB. LIB được tạo nên dựa vào giao thức phân phối nhãn và từ LIB kết hợp với FIB tạo ra LFIB.

Thuật toán chuyển tiếp nhãn (Label Forwarding Algorithm)

Bộ chuyển nhãn sử dụng một thuật toán chuyển tiếp dựa vào việc hoán đổi nhãn. Nút MPLS lấy giá trị trong nhãn của gói vừa đến làm chỉ mục đến LFIB. Khi giá trị nhãn tương ứng được tìm thấy, MPLS sẽ thay thế nhãn trong gói đó bằng nhãn ra (outgoing label) từ mục con (subentry) và gửi gói qua giao tiếp ngõ ra tương ứng đến trạm kế đã được xác định. Nếu nút MPLS chứa nhiều LFIB trên mỗi giao tiếp, nó sử dụng giao tiếp vật lý nơi gói đến để chọn một LFIB cụ thể phục vụ chuyển tiếp gói. Các thuật



toán chuyển tiếp thông thường sử dụng nhiều thuật toán như unicast, multicast và các gói unicast có thiết lập bit ToS. Tuy nhiên, MPLS chỉ dùng một thuật toán chuyển tiếp dựa trên sự hoán đổi nhãn (Label swapping). Một nút MPLS truy xuất bộ nhớ đơn để lấy ra các thông tin như quyết định dành ra tài nguyên cần thiết để chuyển tiếp gói. Khả năng chuyển tiếp và tra cứu tốc độ nhanh giúp chuyển nhãn (label switching) trở thành công nghệ chuyển mạch có tính thực thi cao. MPLS còn có thể dùng để chuyển vận các giao thức lớp ba khác như IPv6, IPX, hoặc Apple Talk. Các thuộc tính này giúp MPLS có thể tương thích tốt với việc chuyển đổi các mạng từ IPv4 lên IPv6.

Hoạt động chuyển tiếp của MPLS

Thực hiện chuyển tiếp dữ liệu với MPLS gồm các bước sau: - Gán nhãn MPLS (trên LSR). - Giao thức phân phối nhãn (LDP - label distribution protocol hay TDP - tag

distribution protocol ) thực hiện gán nhãn và trao đổi nhãn giữa các LSR trong miền MPLS để thiết lập các phiên làm việc (session). Việc gán nhãn có thể gán cục bộ trên router hoặc trên giao tiếp của router.

- Thiết lập LDP/TDP giữa LSR/ELSR. - Mặc định trên router sử dụng LDP.

Cấu hình: Router(config)#mpls label protocol {ldp | tdp}

Thực hiện lệnh khi router không măc định dùng LDP hoặc muốn chuyển từ LDP sang TDP. Lệnh này có thể được cấu hình toàn cục hoặc trên giao tiếp: Router(config-if)#mpls label protocol {ldp | tdp}

Nếu cấu hình trên giao tiếp thì nó sẽ ghi đè lên lệnh toàn cục. TDP dùng cổng TCP 711. LDP dùng cổng TCP 646.

Có 4 loại thông điệp LDP: Discovery: quảng cáo và chấp nhận sự có mặt của LSR trong mạng. Session: Thiết lập, bảo dưỡng và hủy phiên làm việc giữa các LSR. Advertisement: quảng cáo ánh xạ nhãn tới FEC Notification: báo hiệu lỗi.



Phân phối nhãn bằng giao thức phân phối nhãn LDP Trong một miền MPLS, một nhãn gán tới một địa chỉ (FIB) đích được phân phối tới các láng giềng ngược dòng sau khi thiết lập session. Việc kết nối giữa mạng cụ thể với nhãn cục bộ và một nhãn trạm kế (nhận từ router xuôi dòng) được lưu trữ trong LFIB và LIB. MPLS dùng các phương thức phân phối nhãn như sau:

- Yêu cầu xuôi dòng (Downstream on demand). - Tự nguyện xuôi dòng (Unsolicited downstream).

Sự duy trì nhãn MPLS



Có hai chế độ duy trì nhãn:

Chế độ duy trì nhãn tự do (liberal label retention mode): duy trì kết nối giữa nhãn và mạng đích nhưng không lưu giữ trạm kế cho đích đến đó. LSR có thể chuyển tiếp gói ngay khi IGP hội tụ và số lượng nhãn lưu giữ rất lớn cho từng đích đến cụ thể nên tốn bộ nhớ.

Chế độ duy trì nhãn thường xuyên (conservative label retention mode): duy trì nhãn dựa vào hồi đáp LDP hay TDP của trạm kế. Nó hủy các kết nối từ LSR xuôi dòng mà không phải trạm kế của đích đến chỉ định nên giảm thiểu được bộ nhớ.

Các loại nhãn đặc biệt Untagged: gói MPLS đến được chuyển thành một gói IP và chuyển tiếp đến đích. Nó được dùng trong thực thi MPLS VPN.

Nhãn Implicit-null hay POP: Nhãn này được gán khi nhãn trên (top label) của gói MPLS đến bị bóc ra và gói MPLS hay IP được chuyển tiếp tới trạm kế xuôi dòng. Giá trị của nhãn này là 3 (trường nhãn 20 bit). Nhãn này được dùng trong mạng MPLS cho những trạm kế cuối.

Nhãn Explicit-null: được gán để giữ giá trị EXP cho nhãn trên (top label) của gói đến. Nhãn trên được hoán đổi với giá trị 0 và chuyển tiếp như một gói MPLS tới trạm kế xuôi dòng. Nhãn này sử dụng khi thực hiện QoS với MPLS.

Nhãn Aggregate: với nhãn này, khi gói MPLS đến nó bị bóc tất cả nhãn trong chồng nhãn ra để trở thành một gói IP và thực hiện tra cứu trong FIB để xác định giao tiếp ngõ ra cho nó.



Chương 2: CẤU HÌNH MPLS CƠ BẢN

Cấu hình và kiểm chứng MPLS ở chế độ khung (Frame-mode MPLS)

Ở chế độ khung, MPLS sử dụng một nhãn 32 bit chèn vào giữa tiêu đề lớp 2 và lớp 3. Các dạng đóng gói lớp 2 như HDLC, PPP, Frame Relay, và Ethernet dựa trên kiểu khung (frame) nên có thể hoạt động ở chế độ khung (frame mode) hoặc chế độ tế bào (cell mode), ngoại trừ ATM chỉ hoạt động ở chế độ tế bào.

Basic frame-mode MPLS

Biểu đồ tiến trình cấu hình Frame-Mode MPLS



Các bước cấu hình frame-mode MPLS cơ bản

Các bước cấu hình dựa trên sơ đồ trên. Bước 1: Cho phép CEF CEF là một thành phần thiết yếu cho chuyển mạch nhãn (label switching) và chịu trách nhiệm sắp xếp và cài đặt nhãn trong một mạng MPLS. Cấu hình CEF toàn cục trên các router R1, R2, R3 và R4 bằng lệnh: Router(config)#ip cef [distributed]. Chắc chắn rằng CEF được cho phép trên giao tiếp. Nếu không được thì có thể cho phép CEF trên giao tiếp bằng cách dùng lệnh: Router(config-if)#ip route-cache cef. Dùng từ khóa [distribute] thể hiện khả năng của chuyển mạch CEF được chia sẻ. Bước 2: Cấu hình giao thức định tuyến IGP Ở đây ta xét giao thức OSPF. Cho phép các giao tiếp trên các router tham gia vào mạng của nhà cung cấp bằng lệnh : Router(config)#router ospf process-id Router(config-router)#network ip-address wild-card mask area area-id

Cho phép giao thức phân phối nhãn là một bước tùy chọn. Ngầm định, LDP là giao thức phân phối nhãn. Lệnh mpls label protocol {ldp | tdp} chỉ được dùng nếu LDP không phải là giao thức ngầm định hoặc nếu muốn chuyển đổi qua lại giữa LDP và TDP. Lệnh này nên cấu hình trong chế độ toàn cục ( Router(config)# ) tốt hơn trên giao tiếp ( Router(config-if)# ). Tuy nhiên lệnh cấu hình trên giao tiếp sẽ ghi đè lên lệnh cấu hình toàn cục.

Bước 3: Gán LDP router ID



LDP sử dụng địa chỉ IP cao nhất trên một giao tiếp loopback như là một LDP router ID . Nếu không có địa chỉ loopback thì địa chỉ IP cao nhất trên router sẽ trở thành LDP router ID. Muốn buộc một giao tiếp trở thành LDP router ID dùng lệnh: Router(config)#mpls ldp router-id {interface | ip-address} [force] Giao tiếp loopback được khuyến khích vì chúng luôn hoạt động.

Bước 4: Cho phép Ipv4 MPLS hay chuyển tiếp nhãn trên giao tiếp Router(config-if)#mpls ip Ki ểm tra hoạt động của frame-mode MPLS cơ bản: Kiểm tra sự cho phép CEF trên router: Router#show ip cef Xác định chuyển tiếp MPLS được cho phép trên giao tiếp : Router#show mpls interfaces Xem trạng thái của tiến trình khám phá LDP. Hiển thị thông tin khám phá LDP của láng giềng và các giao tiếp mà tiến trình khám phá LDP đang chạy. Router#show mpls ldp discovery Trường xmit/recv thể hiện giao tiếp đang truyền và nhận các gói LDP discovery Hello. Xác định trạng thái các phiên làm việc với láng giềng LDP: Router#show mpls ldp neighbor

Sự chuyển tiếp ở mặt phẳng điều khiển và mặt phẳng dữ liệu

Mặt phẳng điều khiển

Hình trên thể hiện hoạt động của mặp phẳng điều khiển cho prefix 10.10.10.101/32 từ R1 đến R4. Các bước sau thể hiện tiến trình quảng bá nhãn cho prefix 10.10.10.101/32:



Bước 1: R1 gửi một implicit null hay POP label tới R2. Giá trị 3 đại diện cho nhãn implicit-null. R1 quảng bá (propagates) implicit-null đến R2, R2 thực hiện chức năng POP dữ liệu chuyển tiếp từ R4 tới 10.10.10.101/32. Nếu R1 quảng bá một nhãn explicit-null, LSR R2 ngược dòng không POP nhãn nhưng gán một giá trị nhãn là 0 và gửi một gói được gán nhãn tới R2.

Ví dụ : R1#show mpls ldp bindings <output truncated> tib entry: 10.10.10.101/32, rev 4 local binding: tag: imp-null remote binding: tsr: 10.10.10.102:0, tag: 16

Bước 2 : R2 gán một LSP label tới 10.10.10.101/32. Giá trị nhãn này được quảng bá tới R3. Giá trị này được R3 áp đặt trên đường chuyển tiếp dữ liệu.

Bước 3 : trên R3, prefix 10.10.10.101/32 được gán một nhãn cục bộ là 17 và một nhãn ra 16. Nhãn ra được nhận từ R2. Nhãn cục bộ 17 được quảng bá bằng sự chia sẻ nhãn đến R4. Nhãn 17 được R4 dùng để chuyển tiếp dữ liệu đến 10.10.10.101/32.

Hoạt động chuyển tiếp dữ liệu

Các bước sau biểu diễn đường chuyển tiếp dữ liệu từ R4 tới 10.10.10.101/32

R4 áp đặt nhãn 17 lên gói dữ liệu từ R4 tới 10.10.10.101/32. R3 thực hiện tra cứu LFIB (LFIB lookup) và hoán đổi nhãn 17 thành 16 và chuyển tiếp gói dữ liệi tới R2. R2 nhận gói dữ liệu từ R3, thực hiện chức năng pop của trạm kế cuối, bóc nhãn 16 và chuyển tiếp gói dữ liệu tới R1.

LAB 2-1: Cấu hình MPLS frame-mode cơ bản

Mô tả

Cấu hình và kiểm tra

LSR1#show run Building configuration...



Current configuration : 912 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname LSR1 ! logging queue-limit 100 ! ip subnet-zero ! ip cef mpls ldp logging neighbor-changes tag-switching tdp router-id Loopback0 ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Serial0/1 ip address 10.10.10.1 255.255.255.252 tag-switching ip clockrate 72000 ! router ospf 100 log-adjacency-changes network 10.10.10.0 0.0.0.255 area 0 ! ip http server ip classless end LSR1#show ip route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks O 10.10.10.8/30 [110/192] via 10.10.10.2, 00:02:58, Serial0/1 C 10.10.10.0/30 is directly connected, Serial0/1 O 10.10.10.4/30 [110/128] via 10.10.10.2, 00:02:58, Serial0/1 O 10.10.10.104/32 [110/193] via 10.10.10.2, 00:02:58, Serial0/1 O 10.10.10.102/32 [110/65] via 10.10.10.2, 00:02:58, Serial0/1 O 10.10.10.103/32 [110/129] via 10.10.10.2, 00:02:58, Serial0/1 C 10.10.10.101/32 is directly connected, Loopback0 LSR1#show ip cef Prefix Next Hop Interface 0.0.0.0/0 drop Null0 (default route handler entry) 0.0.0.0/32 receive



10.10.10.0/30 attached Serial0/1 10.10.10.0/32 receive 10.10.10.1/32 receive 10.10.10.3/32 receive 10.10.10.4/30 10.10.10.2 Serial0/1 10.10.10.8/30 10.10.10.2 Serial0/1 10.10.10.101/32 receive 10.10.10.102/32 10.10.10.2 Serial0/1 10.10.10.103/32 10.10.10.2 Serial0/1 10.10.10.104/32 10.10.10.2 Serial0/1 224.0.0.0/4 drop 224.0.0.0/24 receive 255.255.255.255/32 receive

LSR1#show cef int s0/1

Serial0/1 is up (if_number 5) Corresponding hwidb fast_if_number 5 Corresponding hwidb firstsw->if_number 5 Internet address is 10.10.10.1/30 ICMP redirects are always sent Per packet load-sharing is disabled IP unicast RPF check is disabled Inbound access list is not set Outbound access list is not set IP policy routing is disabled BGP based policy accounting is disabled Interface is marked as point to point interface Hardware idb is Serial0/1 Fast switching type 4, interface type 60 IP CEF switching enabled IP CEF Fast switching turbo vector Input fast flags 0x0, Output fast flags 0x0 ifindex 4(4) Slot 0 Slot unit 1 Unit 1 VC -1 Transmit limit accumulator 0x0 (0x0) IP MTU 1500 LSR1#show mpls interfaces Interface IP Tunnel Operational Serial0/1 Yes (tdp) No Yes LSR1#show mpls ldp discovery Local LDP Identifier: 10.10.10.101:0 Discovery Sources: Interfaces: Serial0/1 (tdp): xmit LSR2#show run !



hostname LSR2 ! logging queue-limit 100 ! memory-size iomem 10 ip subnet-zero ! ! ! ip cef mpls ldp logging neighbor-changes tag-switching tdp router-id Loopback0 ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Serial0/0 ip address 10.10.10.2 255.255.255.252 mpls label protocol ldp tag-switching ip ! interface Serial0/1 ip address 10.10.10.5 255.255.255.252 mpls label protocol ldp tag-switching ip ! router ospf 100 log-adjacency-changes network 10.10.10.0 0.0.0.255 area 0 ! end LSR2#show cdp nei ….. Device ID Local Intrfce Holdtme Capability Platform Port ID LSR1 Ser 0/0 173 R 2610 Ser 0/1 LSR3 Ser 0/1 125 R 2610 Ser 0/1 LSR2#show ip route ….. Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks O 10.10.10.8/30 [110/128] via 10.10.10.6, 00:23:26, Serial0/1 C 10.10.10.0/30 is directly connected, Serial0/0 C 10.10.10.4/30 is directly connected, Serial0/1 O 10.10.10.104/32 [110/129] via 10.10.10.6, 00:23:26, Serial0/1 C 10.10.10.102/32 is directly connected, Loopback0 O 10.10.10.103/32 [110/65] via 10.10.10.6, 00:23:26, Serial0/1 O 10.10.10.101/32 [110/65] via 10.10.10.1, 00:23:26, Serial0/0



LSR2#show ip cef Prefix Next Hop Interface 0.0.0.0/0 drop Null0 (default route handler entry) 0.0.0.0/32 receive 10.10.10.0/30 attached Serial0/0 10.10.10.0/32 receive 10.10.10.2/32 receive 10.10.10.3/32 receive 10.10.10.4/30 attached Serial0/1 10.10.10.4/32 receive 10.10.10.5/32 receive 10.10.10.7/32 receive 10.10.10.8/30 10.10.10.6 Serial0/1 10.10.10.101/32 10.10.10.1 Serial0/0 10.10.10.102/32 receive 10.10.10.103/32 10.10.10.6 Serial0/1 10.10.10.104/32 10.10.10.6 Serial0/1 224.0.0.0/4 drop 224.0.0.0/24 receive 255.255.255.255/32 receive LSR2#show cef int s0/0 Serial0/0 is up (if_number 4) Corresponding hwidb fast_if_number 4 Corresponding hwidb firstsw->if_number 4 Internet address is 10.10.10.2/30 ICMP redirects are always sent Per packet load-sharing is disabled IP unicast RPF check is disabled Inbound access list is not set Outbound access list is not set IP policy routing is disabled BGP based policy accounting is disabled Interface is marked as point to point interface Hardware idb is Serial0/0 Fast switching type 4, interface type 60 IP CEF switching enabled IP CEF Fast switching turbo vector Input fast flags 0x0, Output fast flags 0x0 ifindex 3(3) Slot 0 Slot unit 0 Unit 0 VC -1 Transmit limit accumulator 0x0 (0x0) IP MTU 1500 LSR2#show cef int s0/1 Serial0/1 is up (if_number 5) Corresponding hwidb fast_if_number 5 Corresponding hwidb firstsw->if_number 5 Internet address is 10.10.10.5/30



ICMP redirects are always sent Per packet load-sharing is disabled IP unicast RPF check is disabled Inbound access list is not set Outbound access list is not set IP policy routing is disabled BGP based policy accounting is disabled Interface is marked as point to point interface Hardware idb is Serial0/1 Fast switching type 4, interface type 60 IP CEF switching enabled IP CEF Fast switching turbo vector Input fast flags 0x0, Output fast flags 0x0 ifindex 4(4) Slot 0 Slot unit 1 Unit 1 VC -1 Transmit limit accumulator 0x0 (0x0) IP MTU 1500 LSR2#show mpls int Interface IP Tunnel Operational Serial0/0 Yes (ldp) No Yes Serial0/1 Yes (ldp) No Yes LSR2#show mpls ldp dis Local LDP Identifier: 10.10.10.102:0 Discovery Sources: Interfaces: Serial0/0 (ldp): xmit Serial0/1 (ldp): xmit/recv LDP Id: 10.10.10.103:0 LSR2#show mpls ldp nei Peer LDP Ident: 10.10.10.103:0; Local LDP Ident 10.10.10.102:0 TCP connection: 10.10.10.103.11010 - 10.10.10.102.646 State: Oper; Ms LSR3#show run Building configuration... Current configuration : 947 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname LSR3 ! logging queue-limit 100



! ip subnet-zero ! ! ! ip cef mpls label protocol ldp mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.103 255.255.255.255 ! interface Serial0/0 ip address 10.10.10.9 255.255.255.252 tag-switching ip clockrate 72000 no fair-queue ! interface Serial0/1 ip address 10.10.10.6 255.255.255.252 tag-switching ip clockrate 72000 ! router ospf 100 log-adjacency-changes network 10.10.10.0 0.0.0.255 area 0 ! end LSR3#show ip route …. Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks C 10.10.10.8/30 is directly connected, Serial0/0 O 10.10.10.0/30 [110/128] via 10.10.10.5, 00:11:19, Serial0/1 C 10.10.10.4/30 is directly connected, Serial0/1 O 10.10.10.104/32 [110/65] via 10.10.10.10, 00:11:19, Serial0/0 O 10.10.10.102/32 [110/65] via 10.10.10.5, 00:11:19, Serial0/1 C 10.10.10.103/32 is directly connected, Loopback0 O 10.10.10.101/32 [110/129] via 10.10.10.5, 00:11:19, Serial0/1 LSR3# show cdp nei Device ID Local Intrfce Holdtme Capability Platform Port ID LSR4 Ser 0/0 131 R 2610 Ser 0/1 LSR2 Ser 0/1 178 R 2610 Ser 0/1 LSR3#show ip cef Prefix Next Hop Interface



0.0.0.0/0 drop Null0 (default route handler entry) 0.0.0.0/32 receive 10.10.10.0/30 10.10.10.5 Serial0/1 10.10.10.4/30 attached Serial0/1 10.10.10.4/32 receive 10.10.10.6/32 receive 10.10.10.7/32 receive 10.10.10.8/30 attached Serial0/0 10.10.10.8/32 receive 10.10.10.9/32 receive 10.10.10.11/32 receive 10.10.10.101/32 10.10.10.5 Serial0/1 10.10.10.102/32 10.10.10.5 Serial0/1 10.10.10.103/32 receive 10.10.10.104/32 10.10.10.10 Serial0/0 224.0.0.0/4 drop 224.0.0.0/24 receive 255.255.255.255/32 receive LSR3#show cef int s0/0 Serial0/0 is up (if_number 4) Corresponding hwidb fast_if_number 4 Corresponding hwidb firstsw->if_number 4 Internet address is 10.10.10.9/30 ICMP redirects are always sent Per packet load-sharing is disabled IP unicast RPF check is disabled Inbound access list is not set Outbound access list is not set IP policy routing is disabled BGP based policy accounting is disabled Interface is marked as point to point interface Hardware idb is Serial0/0 Fast switching type 4, interface type 60 IP CEF switching enabled IP CEF Fast switching turbo vector Input fast flags 0x0, Output fast flags 0x0 ifindex 3(3) Slot 0 Slot unit 0 Unit 0 VC -1 Transmit limit accumulator 0x0 (0x0) IP MTU 1500

LSR3#show cef int s0/1

Serial0/1 is up (if_number 5) Corresponding hwidb fast_if_number 5 Corresponding hwidb firstsw->if_number 5 Internet address is 10.10.10.6/30 ICMP redirects are always sent Per packet load-sharing is disabled IP unicast RPF check is disabled



Inbound access list is not set Outbound access list is not set IP policy routing is disabled BGP based policy accounting is disabled Interface is marked as point to point interface Hardware idb is Serial0/1 Fast switching type 4, interface type 60 IP CEF switching enabled IP CEF Fast switching turbo vector Input fast flags 0x0, Output fast flags 0x0 ifindex 4(4) Slot 0 Slot unit 1 Unit 1 VC -1 Transmit limit accumulator 0x0 (0x0) IP MTU 1500 LSR3#show mpls interfaces Interface IP Tunnel Operational Serial0/0 Yes (ldp) No Yes Serial0/1 Yes (ldp) No Yes

LSR3#show mpls ldp dis Local LDP Identifier: 10.10.10.103:0 Discovery Sources: Interfaces: Serial0/0 (ldp): xmit/recv LDP Id: 10.10.10.104:0 Serial0/1 (ldp): xmit/recv LDP Id: 10.10.10.102:0

LSR3#show mpls ldp nei Peer LDP Ident: 10.10.10.102:0; Local LDP Ident 10.10.10.103:0 TCP connection: 10.10.10.102.646 - 10.10.10.103.11010 State: Oper; Msgs sent/rcvd: 53/49; Downstream Up time: 00:32:45 LDP discovery sources: Serial0/1, Src IP addr: 10.10.10.5 Addresses bound to peer LDP Ident: 10.10.10.102 10.10.10.2 10.10.10.5 Peer LDP Ident: 10.10.10.104:0; Local LDP Ident 10.10.10.103:0 TCP connection: 10.10.10.104.11004 - 10.10.10.103.646 State: Oper; Msgs sent/rcvd: 24/24; Downstream Up time: 00:12:43 LDP discovery sources: Serial0/0, Src IP addr: 10.10.10.10 Addresses bound to peer LDP Ident: 10.10.10.104 10.10.10.10 LSR4#show run Building configuration... !



version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname LSR4 ! logging queue-limit 100 ! memory-size iomem 10 ip subnet-zero ! ip cef mpls label protocol ldp mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.104 255.255.255.255 ! interface Serial0/1 ip address 10.10.10.10 255.255.255.252 tag-switching ip ! router ospf 100 log-adjacency-changes network 10.10.10.0 0.0.0.255 area 0 ! end LSR4#show cdp nei Device ID Local Intrfce Holdtme Capability Platform Port ID LSR3 Ser 0/1 159 R 2610 Ser 0/0 LSR4#show ip route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks C 10.10.10.8/30 is directly connected, Serial0/1 O 10.10.10.0/30 [110/192] via 10.10.10.9, 00:13:46, Serial0/1 O 10.10.10.4/30 [110/128] via 10.10.10.9, 00:13:46, Serial0/1 C 10.10.10.104/32 is directly connected, Loopback0 O 10.10.10.102/32 [110/129] via 10.10.10.9, 00:13:46, Serial0/1 O 10.10.10.103/32 [110/65] via 10.10.10.9, 00:13:46, Serial0/1 O 10.10.10.101/32 [110/193] via 10.10.10.9, 00:13:46, Serial0/1 LSR4#show ip cef Prefix Next Hop Interface 0.0.0.0/0 drop Null0 (default route handler entry) 0.0.0.0/32 receive



10.10.10.0/30 10.10.10.9 Serial0/1 10.10.10.4/30 10.10.10.9 Serial0/1 10.10.10.8/30 attached Serial0/1 10.10.10.8/32 receive 10.10.10.10/32 receive 10.10.10.11/32 receive 10.10.10.101/32 10.10.10.9 Serial0/1 10.10.10.102/32 10.10.10.9 Serial0/1 10.10.10.103/32 10.10.10.9 Serial0/1 10.10.10.104/32 receive 224.0.0.0/4 drop 224.0.0.0/24 receive 255.255.255.255/32 receive LSR4#show cef int s0/1 Serial0/1 is up (if_number 5) Corresponding hwidb fast_if_number 5 Corresponding hwidb firstsw->if_number 5 Internet address is 10.10.10.10/30 ICMP redirects are always sent Per packet load-sharing is disabled IP unicast RPF check is disabled Inbound access list is not set Outbound access list is not set IP policy routing is disabled BGP based policy accounting is disabled Interface is marked as point to point interface Hardware idb is Serial0/1 Fast switching type 4, interface type 60 IP CEF switching enabled IP CEF Fast switching turbo vector Input fast flags 0x0, Output fast flags 0x0 ifindex 4(4) Slot 0 Slot unit 1 Unit 1 VC -1 Transmit limit accumulator 0x0 (0x0) IP MTU 1500

LSR4#show mpls int Interface IP Tunnel Operational Serial0/1 Yes (ldp) No Yes LSR4#show mpls ldp dis Local LDP Identifier: 10.10.10.104:0 Discovery Sources: Interfaces: Serial0/1 (ldp): xmit/recv LDP Id: 10.10.10.103:0

LSR4#show mpls ldp nei Peer LDP Ident: 10.10.10.103:0; Local LDP Ident 10.10.10.104:0 TCP connection: 10.10.10.103.646 - 10.10.10.104.11004



State: Oper; Msgs sent/rcvd: 26/26; Downstream Up time: 00:14:34 LDP discovery sources: Serial0/1, Src IP addr: 10.10.10.9 Addresses bound to peer LDP Ident: 10.10.10.103 10.10.10.6 10.10.10.9



Chương 3: TỔNG QUAN VỀ MPLS VPN

Tổng quan về VPN

VPN được giới thiệu để cho phép các nhà cung cấp dịch vụ sử dụng cơ sở hạ tầng công cộng có sẵn để thực thi các kết nối point-to-point giữa các site khách hàng. Một mạng khách hàng thực thi với bất kỳ công nghệ VPN nào sẽ nằm trong vùng điều khiển của khách hàng được gọi là các site khách hàng, các site này được kết nối với nhau thông qua mạng của nhà cung cấp dịch vụ (SP – service provider). Trong các mạng dựa trên bộ định tuyến truyền thống (traditional router-based network), các site khác nhau của cùng khách hàng được kết nối với nhau bằng các kết nối point-to-point chuyên dụng (lease line, Frame Relay,…). Chi phí thực hiện phụ thuộc vào số lượng site khách hàng. Các site kết nối dạng full mesh sẽ làm gia tăng chi phí theo cấp số mũ. Frame Relay và ATM là những công nghệ đi đầu thích hợp thực thi VPN. Các mạng này bao gồm các thiết bị khác nhau thuộc về khách hàng hoặc nhà cung cấp dịch vụ, đó là các thành phần của giải pháp VPN.

Nhìn chung, VPN gồm các vùng sau:

- Mạng khách hàng (Customer network) – gồm các router tại các site khách hàng khác nhau. Các router kết nối các site cá nhân với mạng của nhà cung cấp được gọi là các router biên phía khách hàng (CE – customer edge).

- Mạng nhà cung cấp (Provider network) – được dùng để cung cấp các kết nối point-to-point qua hạ tầng mạng của nhà cung cấp dịch vụ. Các thiết bị của nhà cung cấp dịch vụ mà nối trực tiếp vối CE router được gọi là router biên phía nhà cung cấp (PE – Provifer edge). Mạng của nhà cung cấp còn có các thiết bị dùng để chuyển tiếp dữ liệu trong mạng trục (SP backbone) được gọi là các rouer nhà cung cấp (P - Provider). Dựa trên sự tham gia của nhà cung cấp dịch vụ trong việc định tuyến cho khách hàng, VPN có thể chia thành hai loại mô hình: Overlay và Peer-to-peer.

Khi Frame Relay và ATM cung cấp cho khách hàng các mạng riêng, nhà cung cấp không thể tham gia vào việc định tuyến khách hàng. Các nhà cung cấp dịch vụ chỉ vận chuyển dữ liệu qua các kết nối point-to-point ảo. Như vậy nhà cung cấp chỉ cung cấp cho khách hàng kết nối ảo tại lớp 2; Đó là mô hình Overlay. Nếu mạch ảo là cố định, sẵn sàng cho khách hàng sử dụng mọi lúc thì được gọi là mạch ảo cố định (PVC – permanent virtual circuit). Nếu mạch ảo được thiết lập theo yêu cầu (on-demand) thì được gọi là mạch ảo chuyển đổi (SVC – switch virtual circuit). Hạn chế chính của mô hình Overlay là các mạch ảo của các site khách hàng kết nối dạng full mesh (ngoại trừ triển khai dạng hub-and-spoke hay partial hub-and-spoke). Nếu có N site khách hàng thì tổng số lượng mạch ảo cần thiết cho việc tối ưu định tuyến là N(N-1)/2.

Ban đầu Overlay VPN được thực thi bởi SP để cung cấp các kết nối lớp 1 (physical layer) hay mạch chuyển vận lớp 2 (dữ liệu dạng frame hoặc cell) giữa các site khách hàng bằng cách sử dụng các thiết bị Frame Relay hay ATM switch làm PE. Do đó nhà cung cấp dịch vụ không thể nhận biết được việc định tuyến ở phía khách hàng. Sau đó, Overlay VPN thực thi các dịch vụ qua IP (lớp 3) với các giao thức định đường hầm như L2TP, GRE, và IPSec. Tuy nhiên, dù trong trường hợp nào thì mạng của nhà cung cấp vẫn trong suốt đối với khách hàng, và các giao thức định tuyến chạy trực tiếp giữa các router của khách hàng.



Mô hình ngang cấp (peer-to-peer) được phát triển để khắc phục nhược điểm của mô hình Overlay và cung cấp cho khách hàng cơ chế vận chuyển tối ưu qua SP backbone. Do đó nhà cung cấp dịch vụ có thể tham gia vào việc định tuyến của khách hàng. Trong mô hình peer-to-peer, thông tin định tuyến được trao đổi giữa các router khách hàng và các router của nhà cung cấp dịch vụ, dữ liệu của khách hàng được vận chuyển qua mạng lõi của nhà cung cấp. Thông tin định tuyến của khách hàng được mang giữa các router trong mạng của nhà cung cấp (P và PE), và mạng khách hàng (các CE router). Mô hình này không yêu cầu tạo ra mạch ảo. Quan sát hình trên ta thấy, các CE router trao đổi tuyến với các router PE trong SP domain. Thông tin định tuyến của khách hàng được quảng bá qua SP backbone giữa các PE và P và xác định được đường đi tối ưu từ một site khách hàng đến một site khác. Việc phát hiện các thông tin định tuyến riêng của khác hàng đạt được bằng cách thực hiện lọc gói tại các router kết nối với mạng khách hàng. Địa chỉ IP của khách hàng do nhà cung cấp kiểm soát. Tiến trình này xem như là thực thi các PE peer-topeer chia sẻ (shared PE peer-to-peer).

Hình sau mô tả những việc triển khai mô hình peer-to-peer.



Ki ến trúc và thuật ngữ trong MPLS VPN

Trong kiến trúc mạng MPLS VPN, các router biên mang thông tin định tuyến khách hàng, cung cấp định tuyến tối ưu cho lưu lượng giữa các site của khách hàng. Mô hình MPLS-based VPN cũng giúp cho khách hàng sử dụng không gian địa chỉ trùng lắp (overlapping address spaces), không giống như mô hình peer-to-peer truyền thống trong việc định tuyến lưu lượng khách hàng yêu cầu nhà cung cấp phải gán địa chỉ IP riêng cho mỗi khách hàng (hoặc khách hàng phải thực hiên NAT) để tránh trùng lắp không gian địa chỉ. MPLS VPN là một dạng thực thi đầy đủ của mô hình peer-to-peer; MPLS VPN backbone và các site khách hàng trao đổi thông tin định tuyến lớp 3, và dữ liệu được chuyển tiếp giữa các site khách hàng sử dụng MPLS-enable SP IP backbone. Miền (domain) MPLS VPN, giống như VPN truyền thống, gồm mạng của khách hàng và mạng của nhà cung cấp. Mô hình MPLS VPN giống với mô hình router PE dành riêng (dedicated PE router model) trong các dạng thực thi VPN ngang cấp peer-to-peer VPN. Tuy nhiên, thay vì triển khai các router PE khác nhau cho từng khách hàng, lưu lượng khách hàng được tách riêng trên cùng router PE nhằm cung cấp khả năng kết nối vào mạng của nhà cung cấp cho nhiều khách hàng. Các thành phần của một MPLS VPN được trình bày trong hình sau:

Các thành phần chính của kiến trúc MPLS VPN:

Mạng khách hàng – thường là miền điều khiển của khách hàng gồm các thiết bị hay các router trải rộng trên nhiều site của cùng một khách hàng. Các router CE – là những router trong mạng khách hàng giao tiếp với mạng của nhà cung cấp. Ở hình trên, mạng khách hàng của CustomerA gồm các router CE1-A, CE2-A và các thiết bị trong Site 1 và Site 2 của CustomerA. Các router CE của Customer A là CE1-A và CE2-A, và router CE của Customer B là CE1-B và CE2-B.



Mạng của nhà cung cấp – miền thuộc điều khiển của nhà cung cấp gồm các router biên (edge) và lõi (core) để kết nối các site thuộc vào các khách hàng trong một hạ tầng mạng chia sẻ. Các router PE – là các router trong mạng của nhà cung cấp giao tiếp với router biên của khách hàng. Các router P – router trong lõi của mạng, giao tiếp với các router lõi khác hoặc router biên của nhà cung cấp. Trong hình trên, mạng của nhà cung cấp gồm các router PE1, PE2, P1, P2, P3, và P4. PE1 và PE2 là router biên của nhà cung cấp trong miền MPLS VPN cho khách hàng A và B. Router P1, P2, P3 và P4 là các router nhà cung cấp (provider router).

Mô hình định tuyến MPLS VPN

MPLS VPN giống như mô hình mạng ngang cấp với router dành riêng. Từ một router CE, chỉ cập nhật IPv4, dữ liệu được chuyển tiếp đến router PE. CE không cần bất kỳ một cấu hình riêng biệt nào cho phép nó tham gia vào miền MPLS VPN. Yêu cầu duy nhất trên CE là một giao thức định tuyến (hay tuyến tĩnh(static)/tuyến ngầm định (default)) cho phép nó trao đổi thông tin định tuyến IPv4 với các router PE. Trong mô hình MPLS VPN, router PE thực hiện rất nhiều chức năng. Trước tiên nó phải phân tách lưu lượng khách hàng nếu có nhiều hơn một khách hàng kết nối tới nó. Vì thế, mỗi khách hàng được gắn với một bảng định tuyến độc lập. Định tuyến qua SP backbone thực hiện bằng một tiến trình định tuyến trong bảng định tuyến toàn cục.

Router P cung cấp chuyển mạch nhãn giữa các router biên của nhà cung cấp và không biết đến các tuyến VPN. Các router CE trong mạng khách hàng không nhận biết được các router P và do đó cấu trúc mạng nội bộ của mạng SP trong suốt đối với khách hàng. Hình sau mô tả chức năng của router PE.

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 tables/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ản đị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ảng 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 bối cảnh (context) 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, nghĩa là sử dụng VRF. 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 touter PE thực hiện 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ú ý: 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.

Route Distinguisher, Route Targets, MP-BGP, và Address Families

Trong mô hình MPLS VPN, router 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 router PE để cho phép truyền dữ liệu giữa các site khách hàng qua MPLS VPN backbone. Router 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). Router 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 với RD (route distinguisher) trong bảng định tuyến ảo (virtual routing table) trên một router 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ừ router CE tạo thành địa chỉ 96-bit duy nhất có thể được chuyển vận giữa các router PE trong miền MPLS. Do đó chỉ duy nhất một RD được cấu hình cho 1 VRF trên router



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 router PE trong mạng nhà cung cấp. RD có thể có hai định dạng: dạng địa chỉ IP hoặc chỉ số AS. Hình bên dưới 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:100 và 1:101, ưu tiên quảng bá địa chỉ VPNv4 trên router PE.

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 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 giữa các PE trong một BGP AS được gọi là 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.

Route targets (RT) 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ía 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 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 như hình sau.

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 xảy ra trong suốt quá trình quảng bá tuyến ở hình trên như sau:

Mạng 172.16.10.0/24 được nhận từ CE1-A, tham gia vào VRF CustomerA trên PE1-AS1. 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 router PE1-AS1. 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 ý: RT là cấu hình bắt buộc trong một MPLS VPN cho mọi VRF trên một router, 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 bá 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. Trong hình trên nhãn VPN được mô tả bằng trường V1 và V2.



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. 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. 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.

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.

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ới 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.

Router 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 router P để gán và phân phối nhãn.



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 sau 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.

Các router 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 MPLS VPN backbone gồm các router 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:



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): 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). PE1-AS1 nhận và vận chuyển tuyến Ipv4, 172.16.10.0/24, đến một tuyến VPNv4 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. Sự quảng bá nhãn cho 10.10.10.101/32 từ PE1-AS1 tới PE2-AS2 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: Router 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ó, xá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-AS1 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.

Hoạt động của mặt phẳng dữ liệu MPLS VPN

Việc chuyển tiếp trong mạng MPLS VPN đòi hỏi phải dùng chồng nhãn (label stack).

Nhãn trên (top lable) được gán và hoán đổi (swap) để chuyển tiếp gói dữ liệu đi trong lõi MPLS. Nhãn thứ hai (nhãn VPN) được kết hợp với VRF ở router PE để chuyển tiếp gói đến các CE. Hình sau mô tả các bước trong chuyển tiếp dữ liệu khách hàng của mặt phẳng dữ liệu từ một site khách hàng CE2-A tới CE1-A trong hạ tầng mạng của SP.



Khi dữ liệu được chuyển tiếp tới một mạng cụ thể dọc theo mạng VPN qua lõi MPLS, chỉ có nhãn trên (top lable) trong chồng nhãn bị hoán đổi (swap) khi gói đi qua backbone. Nhãn VPN vẫn giữ nguyên và được bóc ra khi đến router PE ngõ ra (egress)/xuôi dòng(downstream). Mạng gắn với một giao tiếp ngõ ra thuộc vào một VRF cụ thể trên router phụ thuộc vào giá trị của nhãn VPN.

Sau đây là những bước trong vịêc chuyển tiếp của mặt phẳng dữ liệu minh họa cho hình trên: CE2-A tạo ra một gói dữ liệu với địa chỉ nguồn 172.16.20.1 và đích là 172.16.10.1. PE2-AS1 nhận gói dữ liệu, thêm vào nhãn VPN V1 và nhãn LDP L2 rồi chuyển tiếp gói đến P2-AS1. P2-AS1 nhận gói dữ liệu và chuyển đổi (swap) nhãn LDP L2 thành L1. P1-AS1 nhận gói dữ liệu và bóc (pop) nhãn trên (top label) ra vì nó nhận một ánh xạ nhãn implicit-null cho 10.10.10.101/32 từ PE1-AS1. Kết quả, gói được gán nhãn (nhãn VPN là V1) được chuyển tiếp đến PE1-AS1. PE1-AS1 bóc nhãn VPN V1 ra và chuyển tiếp gói dữ liệu đến CE1-A nơi có địa chỉ mạng 172.16.10.0 được định vị. Cấu hình MPLS VPN cơ bản Mô tả

Cấu hình cho router CE

Cấu hình trao đổi tuyến giữa PE và CE bao gồm việc thực thi một giao thức định tuyến (hay tuyến tĩnh (static)/ngầm định (default)) trên các router CE. Cấu hình theo cách của một giao thức định tuyến thông thường. Trên PE, bối cảnh định tuyến (routing context) VRF (hay các bối cảnh họ địa chỉ (address family context)) được yêu cầu để trao đổi tuyến giữa PE và CE. Các tuyến này sau đó được phân phối lẫn nhau nhờ cào tiến trình MP-BGP trên VRF.

Cấu hình chuyển tiếp MPLS và định danh VRF trên PE:

Cấu hình chuyển tiếp MPLS là bước đầu tiên xây dựng MPLS VPN backbone của nhà cung cấp. Các bước tối thiểu để cấu hình chuyển tiếp MPLS trên PE như sau:

1. Cho phép CEF. 2. Cấu hình giao thức định tuyến IGP trên PE. 3. Cấu hình MPLS hay chuyển tiếp nhãn trên giao tiếp PE kết nối với P.

Các bước này đã được giải quyết ở những chương trước nên ở đây ta chỉ quan tâm đến cấu hình định danh VRF.



Cấu hình VRF trên PE

Cấu hình VRF CustomerA trên PE1-AS1 và PE2-AS1 để tạo bảng định tuyến VRF và bảng CEF cho CustomerA. RouterPE(config)#ip vrf CustomerA Xóa một VRF : RouterPE(config-vrf)#no ip vrf CustomerA Chú ý : khi tạo hoặc xóa một VRF sẽ làm mất đi địa chỉ ip trên giao tiếp. Khi đó xuất hiện thông điệp : % IP addresses from all interfaces in VRF CustomerA have been removed

Cấu hình RD

RD tạo bảng chuyển tiếp và định tuyến. RD được thêm vào đầu địa chỉ Ipv4 của khách hàng để chuyển chúng thành địa chỉ VPNv4 duy nhất. Cấu hình thông số RD của VRF: RouterPE(config-vrf)#rd route-distinguisher RD có thể được dùng theo các dạng sau:

� Chỉ số AS-16 bit : chỉ số 32 bit (ví dụ: 1:100) � Địa chỉ IP 32 bit : chỉ số 16 bit (ví dụ: 10.10.10.101:1)

RD chỉ thay đổi khi xóa VRF đi. RD là duy nhất cho một VRF cụ thể. Không có hai VRF trên một router mà cùng giá trị RD. Nếu thiết lập cùng RD cho nhiều VRF trên một router sẽ có thông điệp cảnh báo sau: % Cannot set RD, check if it's unique Cấu hình chính sách nhập (import) và xuất (export)



Cấu hình chính sách nhập và xuất cho các community mở rộng của MP-BGP. Chính sách này dùng để lọc tuyến cho RT cụ thể. Router(config-vrf)#route-target {import | export | both} route-target-ext-community Kết hợp VRF với giao tiếp. Nếu trên giao tiếp cấu hình sẵn địa chỉ IP thì việc kết hợp này sẽ làm mất địa chỉ IP trên giao tiếp đó nên phải cấu hình lại. Ví dụ: PE1-AS1(config)#interface serial4/0 PE1-AS1(config-if)#ip add 172.16.1.1 255.255.255.252 PE1-AS1(config-if)# ip vrf forwarding CustomerA % Interface Serial4/0 IP address 172.16.1.1 removed due to enabling VRF CustomerA PE1-AS1(config-if)#ip add 172.16.1.1 255.255.255.252

Ki ểm chứng cấu hình VRF trên PE:

Kiểm tra sự tồn tại của VRF trên giao tiếp Router#show ip vrf

Liệt kê các giao tiếp hoạt động trong một VRF cụ thể Router#show ip vrf interfaces

Cấu hình định tuyến BGP PE-PE trên router PE:

Cấu hình định tuyến BGP PE-PE là bước kế tiếp trong việc triển khai một MPLS VPN. Mục đích của bước này là chắc rằng các tuyến VPNv4 có thể được chuyển vận qua mạng trục của nhà cung cấp bằng MP-iBGP. Router P là trong suốt đối với tiến trình này nên nó không mang bất kỳ tuyến nào của khách hàng. Các bước cấu hình tuyến BGP PE-PE giữa các PE như sơ đồ sau.



Cấu hình định tuyến BGP trên PE. Cho phép BGP và xác định AS trên router PE1-AS1 và PE2-AS1. Router(config)#router bgp as-number

Cấu hình láng giềng cho MP-iBGP: Router(config-router)#neighbor {ip-address | peer-group-name} remote-as as-number

Cấu hình họ địa chỉ VPNv4 (VPNv4 address family):

Cấu hình trong tiến trình của BGP, cho phép địa chỉ VPNv4 hoạt động tên các láng giềng. Kích hoạt các láng giềng iBGP chuyển vận địa chỉ VPNv4 qua mạng trục của nhà cung cấp dịch vụ.

Router(config-router)#address-family vpnv4 Router(config-router-af)#neighbor {ip-address | peer-group-name | ipv6- address} activate Router(config-router-af)#neighbor {ip-address | peer-group-name | ipv6- address} send-community extended Cấu hình họ địa chỉ Ipv4: PE1-AS1(config-router)#address-family ipv4 vrf CustomerA PE1-AS1(config-router-af)# redistribute connected PE1-AS1(config-router-af)# exit-address-family

Ki ểm chứng và giám sát định tuyến BGP PE-PE trên router PE:

Sử dụng các lệnh sau: show ip bgp vpnv4 * summary show IP bgp vpnv4 all show ip bgp summary show ip bgp neighbor ip-address



Cấu hình trên router P:

Router P là một LSR của mạng MPLS, nên chỉ cần cấu hình các chức năng sau : � Cho phép một giao thức IGP. � Cho phép CEF trên mọi giao tiếp chuyển tiếp MPLS. � Cấu hình LDP để gán và phân phối nhãn.



Chương 4: GIAO THỨC ĐỊNH TUYẾN EIGRP PE-CE

Giao thức định tuyến EIGRP PE-CE

Giao thức định tuyến EIGRP PE-CE được nhà cung cấp dịch vụ sử dụng đối với các khách hàng sử dụng EIGRP làm giao thức định tuyến IGP, vì thế nên dùng EIGRP để trao đổi thông tin định tuyến giữa các site của khách hàng qua một MPLS VPN backbone. Trong môi trường MPLS VPN EIGRP metric phải được mang vào các cập nhật MP-BGP (MP-BGP update). Các thuộc tính BGP extended community giữ nhiệm vụ mang và giữ nguyên metric EIGRP khi đi qua MP-iBGP domain. Các community này xác định các đặc tính bản chất liên quan đến EIGRP như chỉ số AS hay EIGRP cost như băng thông (bandwidth), độ trễ (delay), tải (load), độ tin cậy (reliability), và MTU. Bảng sau mô tả sáu loại extended BGP community được định nghĩa để mang theo các tuyến EIGRP qua MPLS backbone bằng MP-BGP.

EIGRP Attribute

Type Usage Value

General 0x8800 EIGRP General Route Information

Route Flag and Tag

0x8801 EIGRP Route Metric Information and AS

AS and Delay

0x8802 EIGRP Route Metric Information

Reliability, Next Hop, and Bandwidth

0x8803 EIGRP Route Metric Information

Reserve, Load, and Maximum Transmission Unit (MTU)

Metric

0x8804 EIGRP External Route Information

Remote AS and Remote ID

External 0x8805 EIGRP External Route Information

Remote Protocol and Remote Metric

Hình sau mô tả chi tiết các thuộc tính extended BGP community gắn với các tuyến 192.168.20.0 và 192.168.99.0.



Quảng bá tuyến EIGRP

Việc quảng bá tuyến trong mạng MPLS VPN sử dụng định tuyến EIGRP PE-CE dựa trên EIGRP AS được cấu hình trên router PE. Trong môi trường MPLS VPN, EIGRP AS có thể giống hoặc khác nhau trên mọi router PE.

Quảng bá tuyến khi EIGRP AS giống nhau trên mọi PE:

Hình bên dưới mô tả một mạng MPLS VPN cung cấp các dịch vụ MPLS VPN cho Customer A. PE1-AS1 và PE2-AS1 được cấu hình với EIGRP AS 101.

Trình tự thực hiện khi CE2-A gửi 172.16.20.0 và 209.165.201.0 tới CE1-A:

(1) CE2-A redistribute mạng OSPF 209.165.127.0/27 (D EX) và 172.16.20.0/24 (D) cho PE2-AS1.



(2) Bảng định tuyến VRF Cust_A trên PE2-AS1 nhận 172.16.20.0/24 với EIGRP metric 2195456 và 209.165.127.0/27 với EIGRP metric 3097600.

(3) EIGRP metric cho 172.16.20.0 và 209.165.127.0 được sao chép vào extended BGP attribute như BGP MED, các communitie này chứa thông tin EIGRP như AS, MTU, route type, …kèm theo các tuyến EIGRP được redistribute vào MP-BGP. Sau đó các tuyến 172.16.20.0 và 209.165.127.0 được quảng bá tới PE1-AS1 bằng MP-iBGP session.

(4) PE1-AS1 nhận các tuyến BGP VPNv4 172.16.20.0/24 và 209.165.127.0/27 từ PE2-AS1. EIGRP metric của các tuyến này không bị thay đổi khi đi qua MP-BGP backbone.

(5) PE2-AS1 kiểm tra các thuộc tính nhận được trong tuyến và nếu route type là internal (nếu bit MSB trong BGP extended community được thiết lập bằng 0x8800) và AS nguồn trùng khớp với AS trên router nhận thì tuyến đó được quảng bá như một tuyến nội EIGRP (EIGRP internal route). Nếu route type là external (bit MSB được thiết lập bằng 0x8800) thì tuyến đó được quảng bá tới CE là một tuyến ngoại EIGRP (external EIGRP route). PE1-AS1 sử dụng thông tin thuộc tính extended community để cấu trúc lại cập nhật tuyến EIGRP gốc khi redistribute từ MP-BGP vào EIGRP. Dạng này chỉ được thực hiện EIGRP AS của PE2-AS1 và PE1-AS1 bằng nhau. Các PE hoạt động như là các EIGRP query boundary. Trong trường hợp này, AS 101 trùng khớp với AS của PE1-AS1 nên 172.16.20.0/24 được quảng bá là EIGRP internal route và 209.165.127.0/27 được quảng bá là một external route tới CE1-A.

(6) CE1-A nhận 172.16.20.0 và 209.165.127.0.

Quảng bá tuyến khi EIGRP AS khác nhau trên các router PE:

Nếu hai EIGRP AS khác nhau, các nguyên tắc redistribute bình thường được áp dụng. Nghĩa là, các external EIGRP route được tạo ra khi các tuyến của khách hàng được redistribute vào EIGRP từ các cập nhật MP-BGP. Hình sau mô tả một mạng MPLS VPN sử dụng các EIGRP AS khác nhau trên các PE. Vì MPLS backbone là trong suốt đối với giao thức định tuyến ở CE nên không có EIGRP adjacency hay cập nhật EIGRP (EIGRP update) và các query gửi qua các PE.

Trình tự thực hiện từ bước (1) tới (4) giống như phần “Quảng bá tuyến khi EIGRP AS giống nhau trên mọi PE” ngoại trừ các mạng 192.168.99.0 và 192.168.20.0 và metric:



(1) PE2-AS1 kiểm tra các thuộc tính nhận được trong tuyến và nếu route type là internal và AS nguồn không trùng khớp hay nếu route type là external, tuyến đó được quảng bá tới CE thành một external EIGRP route. Tuyến sẽ không sử dụng thông tin extended community vì không xuất phát cùng AS. Route type cho 192.168.20.0 là internal và AS nguồn là 202 không trùng khớp với cấu hình trên PE1-AS1 (201). Do đó, PE1-AS1 quảng bá thành một external route tới CE1-A. Route type của 192.168.99.0 là external nên vì thế cả hai tuyến được quảng bá là external route tới CE1-A.

(2) CE1-A nhận các tuyến 192.168.20.0/24 và 192.168.99.0/24 là các external route.

Sơ đồ cấu hình định tuyến EIGRP PE-CE

Cần lưu ý các điểm sau:

- Chế độ cấu hình address family được sử dụng khi cấu hình EIGRP AS cho VRF.

- Để cho phép sử dụng một tiến trình EIGRP đơn (single EIGRP process), EIGRP AS phải được cấu hình trong chế độ EIGRP address family.

Các bước cấu hình khác giống như cấu hình EIGRP bình thường, metric mặc định sẽ được gán khi redistribute các tuyến không phải là EIGRP (non-EIGRP route).

LAB 4-1: Cấu hình định tuyến EIGRP PE-CE cơ bản

Mô tả

Mục tiêu của bài lab này là minh họa cấu hình EIGRP PE-CE, việc quảng bá tuyến EIGRP khi các PE thuộc vào cùng EIGRP AS và khác EIGRP AS với một VRF. Hình



sau cho thấy một MPLS VPN cung cấp các dịch vụ MPLS VPN cho các site của Customer A và Customer B.

- Mạng của Customer A – Customer A có CE1-A và CE2-A trong cùng VPN-A và cùng thuộc EIGRP AS 101. EIGRP AS 101 được cấu hình cho VRF CustomerA trên PE1-AS1 và PE2-AS1.

- Mạng của Customer B – Customer B có CE1-B và CE2-B trong cùng VPN-B và thuộc hai EIGRP AS khác nhau, 201 và 202. PE1-AS1 và PE2-AS1 cấu hình hai EIGRP AS, 201 và 202, cho VRF CustomerB.

Thực hiện

Các bước cấu hình định tuyến EIGRP PE-CE như sau:

(1) Cho phép tiến trình định tuyến EIGRP toàn cục.

Cho phép tiến trình định tuyến EIGRP toàn cục (global EIGRP routing process) trên các router PE, PE1-AS1 và PE2-AS1.



(2) Định ngữ cảnh (context) và các thông số (parameter) cho định tuyến VRF EIGRP.

- Định ngữ cảnh định tuyến cho VRF CustomerA và CustomerB trong tiến trình EIGRP ở bước 1.

- Cho phép các mạng được định tuyến EIGRP

- Cấu hình no auto-summary.

- Cho phép một tiến trình EIGRP được sử dụng, EIGRP AS phải được cấu hình trong chế độ cấu hình EIGRP address family. Nhiều VRF có thể sử dụng cùng một giá trị EIGRP AS.

Thực hiện cấu hình cho hai bước (1) và (2):

PE1-AS1(config)#router eigrp 1 PE1-AS1(config-router)#address-family ipv4 vrf CustomerB PE1-AS1(config-router-af)# network 172.16.0.0 PE1-AS1(config-router-af)# no auto-summary PE1-AS1(config-router-af)# autonomous-system 201 PE1-AS1(config-router-af)# exit-address-family

PE2-AS1(config)#router eigrp 1 PE2-AS1(config-router)# address-family ipv4 vrf CustomerB PE2-AS1(config-router-af)# network 172.16.0.0 PE2-AS1(config-router-af)# no auto-summary PE2-AS1(config-router-af)# autonomous-system 202 PE2-AS1(config-router-af)# exit-address-family

Thực hiện tương tự cho CustomerA.

(3) Redistribute các tuyến BGP VPNv4 vào EIGRP.

PE1-AS1(config)#router eigrp 1 PE1-AS1(config-router)# address-family ipv4 vrf Cust_A PE1-AS1(config-router-af)# redistribute bgp 1 metric 1000 100 255 1 1500

(4) Redistribute các tuyến EIGRP vào BGP.

PE1-AS1(config)#router bgp 1 PE1-AS1(config-router)#address-family ipv4 vrf Cust_A PE1-AS1(config-router-af)#redistribute eigrp 101

PE2-AS1(config)#router bgp 1 PE2-AS1(config-router)# address-family ipv4 vrf Cust_A PE2-AS1(config-router-af)# redistribute eigrp 101

Thực hiện tương tự để hoàn thành cấu hình cho VRF CustomerA và CustomerB trên các router PE.

Cấu hình

Router P1-AS1

! hostname P1-AS1 ! ip subnet-zero !



ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.200 255.255.255.255 ! interface Serial0/0 description Connected to PE1-AS1 ip address 10.10.10.2 255.255.255.252 tag-switching ip ! interface Serial0/1 description Connected to PE2-AS1 ip address 10.10.10.6 255.255.255.252 tag-switching ip ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! ip http server ip classless ! end

Router PE1-AS1

! hostname PE1-AS1 ! ip subnet-zero ! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip vrf CustomerB rd 1:200 route-target export 1:200 route-target import 1:200 ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Serial0/0 description Connected to P1-AS1 ip address 10.10.10.1 255.255.255.252



tag-switching ip clockrate 64000 no fair-queue ! interface Serial1/1 description Connected to CE1-A ip vrf forwarding CustomerA ip address 172.16.1.1 255.255.255.252 clockrate 64000 ! interface Serial1/3 description Connected to CE1-B ip vrf forwarding CustomerB ip address 192.168.1.1 255.255.255.252 tag-switching ip ! router eigrp 1 auto-summary ! address-family ipv4 vrf CustomerB redistribute bgp 1 metric 1000 100 255 1 1500 network 192.168.1.0 no auto-summary autonomous-system 201 exit-address-family ! address-family ipv4 vrf CustomerA redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.101 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended no auto-summary exit-address-family



! address-family ipv4 vrf CustomerB redistribute eigrp 201 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf CustomerA redistribute eigrp 101 no auto-summary no synchronization exit-address-family ! ip http server ip classless ! end

Router PE2-AS1

! hostname PE2-AS1 ! ip subnet-zero ! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip vrf CustomerB rd 1:200 route-target export 1:200 route-target import 1:200 ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Ethernet0/0 no ip address shutdown half-duplex ! interface Serial0/0 no ip address shutdown no fair-queue !



interface Serial0/1 description Connected to P1-AS1 ip address 10.10.10.5 255.255.255.252 tag-switching ip clockrate 64000 ! interface Serial1/2 description Connected to CE2-A ip vrf forwarding CustomerA ip address 172.16.2.1 255.255.255.252 ! interface Serial1/4 description Connected to CE2-B ip vrf forwarding CustomerB ip address 192.168.2.1 255.255.255.252 clockrate 64000 ! router eigrp 1 auto-summary ! address-family ipv4 vrf CustomerB redistribute bgp 1 metric 1000 100 255 1 1500 network 192.168.2.0 no auto-summary autonomous-system 202 exit-address-family ! address-family ipv4 vrf CustomerA redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.102 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended no auto-summary



exit-address-family ! address-family ipv4 vrf CustomerB redistribute eigrp 202 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf CustomerA redistribute eigrp 101 no auto-summary no synchronization exit-address-family ! ip http server ip classless ! end

Router CE1-A

! hostname CE1-A ! ip subnet-zero ! interface Ethernet0/0 description VPN-A Site 1 network ip address 172.16.10.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE1-AS1 ip address 172.16.1.2 255.255.255.252 no fair-queue ! router eigrp 101 network 172.16.0.0 no auto-summary ! ip http server ip classless ! end

Router CE2-A

! hostname CE2-A ! interface Ethernet0/0



description VPN-A Site 2 network ip address 172.16.20.1 255.255.255.0 no ip directed-broadcast no keepalive ! interface Serial0/0 description Connected to PE2-AS1 ip address 172.16.2.2 255.255.255.252 no ip directed-broadcast no ip mroute-cache no fair-queue clockrate 64000 ! router eigrp 101 network 172.16.0.0 no auto-summary ! ip classless ! end

Router CE1-B

! hostname CE1-B ! ip subnet-zero ! interface Ethernet0/0 description VPN-B Site 1 network ip address 192.168.10.1 255.255.255.0 no ip directed-broadcast no keepalive ! interface Serial0/0 description Connected to PE1-AS1 ip address 192.168.1.2 255.255.255.252 no ip directed-broadcast no ip mroute-cache no fair-queue clockrate 64000 ! router eigrp 201 network 192.168.1.0 network 192.168.10.0 no auto-summary ! ip classless ! end

Router CE2-B



! hostname CE2-B ! ip subnet-zero ! interface Ethernet0/0 description VPN-B Site 2 network ip address 192.168.20.1 255.255.255.0 no ip directed-broadcast no keepalive ! interface Serial0/0 description Connected to PE2-AS1 ip address 192.168.2.2 255.255.255.252 no ip directed-broadcast no ip mroute-cache no fair-queue ! router eigrp 202 network 192.168.2.0 network 192.168.20.0 no auto-summary ! ip classless ! end

Kiểm tra

Các bước kiểm tra định tuyến EIGRP PE-CE như sau:

(1) Kiểm tra quan hệ láng giềng (neighbor) EIGRP trên các router PE.

PE1-AS1#show ip eigrp vrf CustomerA neighbors

IP-EIGRP neighbors for process 201 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 0 192.168.1.2 Se1/3 12 05:27:05 214 1284 0 2

PE2-AS1#show ip eigrp vrf CustomerA neighbors

IP-EIGRP neighbors for process 202 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 0 192.168.2.2 Se1/4 11 05:19:21 903 5000 0 2

(2) Kiểm tra các thuộc tính BGP mở rộng gắn với tuyến 192.168.20.0

PE2-AS1#show ip bgp vpnv4 vrf CustomerB 192.168.20.1

BGP routing table entry for 1:200:192.168.20.0/24, version 9 Paths: (1 available, best #1, table CustomerB) Advertised to non peer-group peers: 10.10.10.101 Local



192.168.2.2 from 0.0.0.0 (10.10.10.102) Origin incomplete, metric 20537600, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:200 0x8800:32768:0 0x8801:202:537600 0x8802:62209:20000000 0x8803:62209:1500

PE1-AS1#show ip bgp vpnv4 vrf CustomerB 192.168.20.1

BGP routing table entry for 1:200:192.168.20.0/24, version 17 Paths: (1 available, best #1, table CustomerB) Not advertised to any peer Local 10.10.10.102 (metric 129) from 10.10.10.102 (10.10.10.102) Origin incomplete, metric 20537600, localpref 100, valid, internal, best Extended Community: RT:1:200 0x8800:32768:0 0x8801:202:537600 0x8802:62209:20000000 0x8803:62209:1500

Ta thấy EIGRP metric không đổi (metric 20537600) khi đi qua MP-BGP domain.

(3) Kiểm việc quảng bá tuyến EIGRP cho CustomerA.

PE2-AS1#show ip route vrf CustomerA eigrp

172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks D 172.16.20.0/24 [90/20537600] via 172.16.2.2, 05:18:44, Serial1/2

PE2-AS1#show ip bgp vpnv4 vrf CustomerA 172.16.20.1

BGP routing table entry for 1:100:172.16.20.0/24, version 7 Paths: (1 available, best #1, table CustomerA) Advertised to non peer-group peers: 10.10.10.101 Local 172.16.2.2 from 0.0.0.0 (10.10.10.102) Origin incomplete, metric 20537600, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 0x8800:32768:0 0x8801:101:537600 0x8802:62209:20000000 0x8803:62209:1500


BGP routing table entry for 1:100:172.16.10.0/24, version 7 Paths: (1 available, best #1, table CustomerA) Advertised to non peer-group peers: 10.10.10.102 Local 172.16.2.2 from 0.0.0.0 (10.10.10.101) Origin incomplete, metric 20537600, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 0x8800:32768:0 0x8801:101:537600 0x8802:62209:20000000 0x8803:62209:1500

(4) Kiểm tra các tuyến EIGRP trên các router CE

CE1-A#show ip route eigrp



172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks D 172.16.20.0/24 [90/21049600] via 172.16.1.1, 04:40:11, Serial0/0 D 172.16.2.0/30 [90/21024000] via 172.16.1.1, 04:40:11, Serial0/0

CE1-B#show ip route eigrp

D EX 192.168.20.0/24 [170/3097600] via 192.168.1.1, 04:38:14, Serial0/0 192.168.2.0/30 is subnetted, 1 subnets D EX 192.168.2.0 [170/3097600] via 192.168.1.1, 04:38:14, Serial0/0

(5) Kiểm tra kết nối giữa các site

CE1-A#ping 172.16.20.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/116/117 ms

CE1-B#ping 192.168.20.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/116/117 ms

Vòng lặp tuyến (Routing loop)

Routing loop có thể xảy ra trong các trường hợp sau:

- Một tuyến nhận được bởi một multihomed site từ backbone qua một kết nối mà có thể chuyển tiếp ngược lại backbone qua kết nối khác.

- Một tuyến xuất phát từ một multihomed site và được gửi tới backbone qua một kết nối có thể trở về từ một kết nối khác.

Multihomed Site gửi lại các tuyến cho Backbone

Hình sau mô tả một mạng MPLS VPN cho Customer A có 3 site, Site 1, Site 2 và Site 3. Site 3 là multihomed. Site 3 nhận được tuyến EIGRP 172.16.20.0/24 và redistribute lại vào backbone tại PE1-AS1.



Thứ tự thực hiện khi tuyến EIGRP được gửi lại vào backbone như sau:

(1) 172.16.20.0/24 được quảng bá là internal route tới PE2-AS1.

(2) PE2-AS1 quảng bá 172.16.20.0/24 tới CE4-A qua EIGRP và gửi 172.16.20.0/24 bằng MP-iBGP session tới PE1-AS1.

(3) CE4-A quảng bá 172.16.20.0/24 là một EIGRP internal route tới CE3-A

(4) CE3-A quảng bá 172.16.20.0/24 là một EIGRP internal route tới PE1-AS1

PE1-AS1 phải ra quyết định chọn đường đi:

- Nếu cập nhật BGP cho 172.16.20.0/24 tới trước, nó sẽ redistribute vào EIGRP và gửi tới CE3-A. Vì composite metric tốt hơn nên nó chọn đường này vì MPLS VPN không thêm vào giới hạn độ trễ (delay) và băng thông (bandwidth). Nghĩa là PE1-AS1 sẽ không bao giờ nhận được một cập nhật thứ hai và chỉ có một đường để đi.

- Nếu tuyến EIGRP tới trước, nó sẽ redistribute vào BGP và gửi lại cho PE2-AS1. PE2-AS1 vẫn chọn đường được cập nhật từ EIGRP.

Hơn nữa, Bảng định tuyến sẽ chọn đường có chỉ số AD (administrative distance) thấp hơn (EIGRP là 90 hoặc 170; iBGP là 200).

Backbone gửi lại tuyến vào Multihomed Site

Trường hợp truyến 172.16.50.0/24 xuất phát từ multihomed site được gửi ngược lại qua kết nối với PE.

Tình trạng này không xảy ra nếu mạng giữ nguyên AD mặc định vì PE ưu tiên cho các tuyến học từ EIGRP hơn.

Đếm ra vô cực (Count to Infinity)

Hình trên cho thấy PE1-AS1 và/hoặc PE2-AS1 có hai đường đi cho 172.16.50.0/24: một học từ MP-iBGP và một học trực tiếp bằng EIGRP. Nếu 172.16.50.0/24 gặp sự cố (down), trình tự xử lý xảy ra như sau:

(1) CE3-A và CE4-A gửi ra các thông điệp truy vấn (query message).



(2) Giả sử PE1-AS1 có hai đường đi như trên, khi nhận 1 query message nó sẽ trả lời với một đường đi liên quan và vẫn còn hoạt động qua MP-iBGP.

(3) CE3-A sẽ nhận được một đường đi tới 172.16.50.0/24 qua PE1-AS1.

(4) PE1-AS1 nhận được một thông điệp hủy tuyến (withdrawal message) từ PE2-AS1.

(5) PE1-AS1 sẽ hủy tuyến mà nó quảng bá tới CE3-A, router này quảng bá thông tin đến cho CE4-A, và CE4-A quảng bá lại cho PE3-AS1.

(6) Query message bắt nguồn từ PE1-AS1 để tìm mạng 172.16.50.0/24. Khi query message đến được PE2-AS1, PE2-AS1 vừa quảng bá một cập nhật tuyến mới đến được cho mạng 172.16.50.0/24 qua MP-iBGP tới PE1-AS1, PE1-AS1 sẽ tạo lại một cập nhật EIGRP để trả lời cho các query trước đó.

(7) Tiến trình lặp của các thông điệp reachable/unreachable tiếp tục đến khi qua một lượng tối đa các hop.

Hiện tượng này được gọi là “count to infinity”.

Định tuyến kém tối ưu (Suboptimal Routing)

Hiện tượng này xảy ra do AD của EIGRP tốt hơn của iBGP. Một bảng định tuyến luôn luôn ưu tiên cho các tuyến học được từ IGP vì có AD nhỏ hơn iBGP. Hình bên dưới cho thấy các gói dữ liệu từ CE1-A tới CE2-A sẽ được chuyển tiếp bởi PE1-AS1 tới cho CE3-A tạo nên định tuyến kém tối ưu.

Lặp tuyến và định tuyến kém tối ưu có thể tránh được bằng cách sử dụng:

- BGP cost community có thể dùng để ép BGP so sánh các tuyến xuất phát từ EIGRP và các tuyến MP-iBGP dựa trên EIGRP metric.

- EIGRP Site of Origin (SoO) trên các router PE và CE có thể dùng để chống lặp tuyến.

BGP Cost Community



BGP cost community (BGP CC) là một thuộc tính community mở rộng mới của BGP. BGP CC là một thuộc tính non-transitive extended community, nó chỉ qua iBGP và các confederation peer nhưng không đến được external BGP peer.

BGP CC cho phép PE so sánh các tuyến đến từ các giao thức khác nhau sử dụng giá trị AD khác nhau dựa trên metric của chúng. Các tuyến BGP mang thuộc tính BGP cost community sẽ dùng EIGRP AD thay vì iBGP AD để so sánh mà không cần cấu hình tĩnh giá trị AD.

Các tuyến được redistribute từ EIGRP vào MP-BGP, chúng sẽ được đánh dấu (tag) với thuộc tính BGP cost community để mang composite EIGRP metric thêm vào các thuộc tính EIGRP riêng. Thuộc tính BGP CC được mô tả trong hình sau:

Giá trị Điểm chèn (POI – point of insertion) để chắc rằng tuyến BGP được chọn sử dụng BGP CC. Điều này cho phép so sánh các tuyến iBGP với các tuyến EIGRP. BGP CC có thể phân biệt giữa các tuyến EIGRP internal và external bằng trường ID: internal có ID là 128, external có ID là 129. Tuyến có BGP CC ID nhỏ nhất sẽ được chọn. Tuyến internal EIGRP có ID thấp hơn tuyến external. Sự lựa chọn tuyến thường dựa trên giá trị trong trường Cost của BGP CC vì nó mang composite EIGRP metric.

Trình tự xảy ra với PE1-AS1 để chọn đường đi tốt nhất dựa trên EIGRP metric và không dựa trên AD giữa EIGRP và iBGP (hình trên):

(1) CE2-A xuất phát tuyến 172.16.20.0/24 tới PE2-AS1.

(2) PE2-AS1 chuyển tiếp tuyến tới CE4-A qua EIGRP và tới PE1-AS1 qua MP-iBGP.



(3) PE1-AS1 nhận hai cập nhật cho 172.16.20.0/24, một qua EIGRP từ CE3-A và một qua MP-iBGP từ PE2-AS1. PE1-AS1 sẽ dùng tuyến học từ MP-iBGP nhờ vào thuộc tính BGP CC.

(4) Các gói từ CE1-A tới CE2-A sẽ được chuyển tiếp bởi PE1-AS1 tới PE2-AS1 vì bảng định tuyến của VRF A chứa tuyến MP-iBGP, tuyến này mang composite EIGRP metric nhỏ hơn.

EIGRP SoO

EIGRP SoO được thêm vào để gắn với các các tuyến internal và external EIGRP. Thuộc tính này được trao đổi tự động giữa các giao thức định tuyến (SoO-cho phép EIGRP và MP-BGP) để chống lặp tuyến trong môi trường multihome nơi có sử dụng redistribute hai chiều. Tất cả các router CE, hay ít nhất tại các multihomed site, phải hỗ trợ đặc tính này để cho phép quảng bá qua VPN. EIGRP SoO được dùng trên PE và CE để chống lặp tuyến hiệu quả nhất. Các tuyến backdoor được cấu hình với EIGRP SoO để hội tụ nhanh nhất cho việc mất tuyến.

Multihomed Site và EIGRP SoO

Các tuyến được đẩy vào một multihomed site và bị tag với một giá trị EIGRP SoO 1:101. Router PE nhận được sẽ kiểm tra mọi cập nhật giá trị SoO được cấu hình trên giao tiếp nhận cập nhật đó. Nếu giá trị bằng nhau, cập nhật đó sẽ bị hủy, giúp chống lặp tuyến và tối ưu việc định tuyến.

Trình tự xảy ra khi 172.16.20.0/24 được quảng bá tới CE1-A:

(1) CE2-A xuất phát một tuyến 172.16.20.0/24.

(2) PE2-AS1 chuyển tiếp tuyến tới CE4-A qua EIGRP và tới PE1-AS1 qua MP-iBGP. Tuyến EIGRP sẽ được tag với thuộc tính EIGRP SoO 1:101 để các định tuyến này đến từ backbone.

(3) CE4-A chuyển tiếp cập nhật 172.16.20.0/24 tới CE3-A.

(4) PE1-AS1 nhận hai cập nhật cho 172.16.20.0/24, một qua EIGRP từ CE3-A và một qua MP-iBGP từ PE2-AS1. PE1-AS1 sẽ sử dụng tuyến học từ BGP; tuyến EIGRP từ CE3-A bị lọc đi vì có cùng giá trị SoO với giao tiếp nhận nó.

Backdoor Link và EIGRP SoO



Tiến trình chọn tuyến như sau:

(1) CE2-A quảng bá 172.16.20.0/24 tới PE2-AS1.

(2) PE2-AS1 chuyển tiếp 172.16.20.0/24, tuyến này tới CE4-A qua EIGRP và tới PE1-AS1 qua MP-iBGP. Tuyến EIGRP sẽ bị tag với giá trị EIGRP SoO là 1:20 để xác định nó đến từ MPLS backbone và được gửi vào Site 4 với giá trị 1:20.

(3) PE1-AS1 nhận hai cập nhật cho 172.16.20.0, một qua EIGRP từ CE2 và một qua MP-iBGP từ PE2. Cập nhật khi đi qua backdoor link sẽ mang EIGRP SoO giá trị 1:20 khi quảng bá tới CE3-A, và CE3-A sử dụng 1:10 để quảng bá tuyến này tới PE1-AS1.

(4) PE1-AS1 nhận hai cập nhật cho 172.16.20.0/24, một qua EIGRP từ CE3-A với SoO 1:10, tuyến này bị lọc vì chứa trùng giá trị SoO với giao tiếp nhận nó và chỉ nhận tuyến qua MP-iBGP từ PE2-AS1.

LAB 4-2: Cấu hình mạng sử dụng BGP CC và EIGRP SoO

Mô tả



Cấu hình

Router P1-AS1 P1-AS1#show run Building configuration... Current configuration : 970 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname P1-AS1 ! logging queue-limit 100 ! ip subnet-zero ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.200 255.255.255.255 ! interface Serial0/0 description Connected to PE1-AS1 ip address 10.10.10.2 255.255.255.252



tag-switching ip clockrate 64000 ! interface Serial0/1 description Connected to PE2-AS1 ip address 10.10.10.6 255.255.255.252 tag-switching ip ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! ip http server ip classless ! end Router PE1-AS1 PE1-AS1#show run Building configuration... Current configuration : 2084 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname PE1-AS1 ! ip subnet-zero ! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Serial0/0 description Connected to P1-AS1 ip address 10.10.10.1 255.255.255.252 tag-switching ip no fair-queue ! interface Serial1/1



description Connected to CE1-A ip vrf forwarding CustomerA ip address 172.16.1.1 255.255.255.252 clockrate 64000 ! interface Serial1/3 description Connected to CE3-A ip vrf forwarding CustomerA ip vrf sitemap SOO-VPNA ip address 172.16.3.1 255.255.255.252 clockrate 64000 ! router eigrp 1 auto-summary ! address-family ipv4 vrf CustomerA redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.101 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community both no auto-summary exit-address-family ! address-family ipv4 vrf CustomerA redistribute eigrp 101 no auto-summary no synchronization exit-address-family ! ip http server ip classless ! route-map SOO-VPNA permit 10



set extcommunity soo 1:10 ! call rsvp-sync ! ! end Router PE2-AS1

PE2-AS1#show run

Building configuration... Current configuration : 2255 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname PE2-AS1 ! logging queue-limit 100 ! memory-size iomem 10 ip subnet-zero ! ! ! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip cef mpls ldp logging neighbor-changes ! ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Ethernet0/0 no ip address shutdown half-duplex ! interface Serial0/1 description Connected to P1-AS1 ip address 10.10.10.5 255.255.255.252 tag-switching ip clockrate 64000 !



interface Serial1/2 description Connected to CE2-A ip vrf forwarding CustomerA ip address 172.16.2.1 255.255.255.252 ! interface Serial1/4 description Connected to CE4-A ip vrf forwarding CustomerA ip vrf sitemap SOO-VPNA ip address 172.16.4.1 255.255.255.252 ! ! router eigrp 1 auto-summary ! address-family ipv4 vrf CustomerA redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.102 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community both no auto-summary exit-address-family ! address-family ipv4 vrf CustomerA redistribute eigrp 101 no auto-summary no synchronization exit-address-family ! ip http server ip classless !



route-map SOO-VPNA permit 10 set extcommunity soo 1:20 ! call rsvp-sync ! ! end

Router CE1-A

CE1-A#show run Building configuration... Current configuration : 817 bytes ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname CE1-A ! logging queue-limit 100 ! ip subnet-zero ! ! ! mpls ldp logging neighbor-changes ! interface Ethernet0/0 description VPN-A Site 1 network ip address 172.16.10.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE1-AS1 ip address 172.16.1.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary ! no ip http server ip classless ! call rsvp-sync ! ! end



Router CE2-A

! hostname CE2-A ! ! memory-size iomem 10 ip subnet-zero ! interface Ethernet0/0 description VPN-A Site 2 network ip address 172.16.20.1 255.255.255.0 no keepalive half-duplex ! interface Serial0/0 description Connected to PE2-AS1 ip address 172.16.2.2 255.255.255.252 clockrate 64000 ! router eigrp 101 network 172.16.0.0 no auto-summary no eigrp log-neighbor-changes ! ip classless ip http server ! call rsvp-sync ! end

Router CE3-A

CE3-A#show run Building configuration... Current configuration : 1034 bytes ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname CE3-A ! logging queue-limit 100 ! ip subnet-zero ! ! no ip domain lookup



! mpls ldp logging neighbor-changes ! interface Ethernet0/0 description VPN-A Site 3 network ip address 172.16.30.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE1-AS1 ip address 172.16.3.2 255.255.255.252 no ip mroute-cache no fair-queue ! interface Serial0/1 description Connected to CE4-A bandwidth 1000 ip vrf sitemap SOO-VPNA ip address 172.16.5.1 255.255.255.252 clockrate 64000 ! router eigrp 101 network 172.16.0.0 no auto-summary ! no ip http server ip classless ! route-map SOO-VPNA permit 10 set extcommunity soo 1:10 ! ! call rsvp-sync ! end

Router CE4-A

CE4-A#show running-config

Building configuration... Current configuration : 1061 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname CE4-A !



logging queue-limit 100 ! ip subnet-zero ! ! ! mpls ldp logging neighbor-changes ! interface Ethernet0/0 description VPN-A Site 4 network ip address 172.16.40.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE2-AS1 ip address 172.16.4.2 255.255.255.252 clockrate 64000 no fair-queue ! interface Serial0/1 description Connected to CE3-A bandwidth 1000 ip vrf sitemap SOO-VPNA ip address 172.16.5.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary ! ip http server ip classless ! route-map SOO-VPNA permit 10 set extcommunity soo 1:200 ! ! call rsvp-sync ! end

Kiểm tra

(1) Kiểm tra đường đi

CE1-A#traceroute 172.16.20.1

Type escape sequence to abort. Tracing the route to 172.16.20.1 1 172.16.1.1 16 msec 16 msec 16 msec 2 172.16.3.2 28 msec 28 msec 28 msec



3 172.16.5.2 44 msec 40 msec 44 msec 4 172.16.4.1 56 msec 56 msec 56 msec 5 172.16.2.2 68 msec 68 msec *


Type escape sequence to abort. Tracing the route to 172.16.40.1 1 172.16.1.1 16 msec 16 msec 16 msec 2 172.16.3.2 28 msec 28 msec 28 msec 3 172.16.5.2 80 msec 40 msec *


Type escape sequence to abort. Tracing the route to 172.16.20.1 1 172.16.5.2 16 msec 16 msec 16 msec 2 172.16.4.1 28 msec 28 msec 28 msec 3 172.16.2.2 45 msec * 41 msec


Type escape sequence to abort. Tracing the route to 172.16.40.1 1 172.16.5.2 16 msec * 13 msec

(2) Kiểm tra các thuộc tính BGP extended community


BGP routing table entry for 1:100:172.16.20.0/24, version 19 Paths: (2 available, best #2, table CustomerA) Advertised to non peer-group peers: 10.10.10.102 Local 10.10.10.102 (metric 129) from 10.10.10.102 (10.10.10.102) Origin incomplete, metric 20537600, localpref 100, valid, internal Extended Community: RT:1:100 0x8800:32768:0 0x8801:101:537600 0x8802:32769:20000000 0x8803:32769:1500 Local 172.16.3.2 from 0.0.0.0 (10.10.10.101) Origin incomplete, metric 22073600, localpref 100, weight 32768, valid, sourced, best Extended Community: SoO:1:10 RT:1:100 0x8800:32768:0 0x8801:101:2073600 0x8802:32772:20000000 0x8803:32769:1500


BGP routing table entry for 1:100:172.16.40.0/24, version 13 Paths: (2 available, best #2, table CustomerA) Advertised to non peer-group peers: 10.10.10.102 Local



10.10.10.102 (metric 129) from 10.10.10.102 (10.10.10.102) Origin incomplete, metric 20537600, localpref 100, valid, internal Extended Community: SoO:1:20 RT:1:100 0x8800:32768:0 0x8801:101:537600 0x8802:61697:20000000 0x8803:61697:1500 Local 172.16.3.2 from 0.0.0.0 (10.10.10.101) Origin incomplete, metric 21049600, localpref 100, weight 32768, valid, sourced, best Extended Community: SoO:1:10 RT:1:100 0x8800:32768:0 0x8801:101:1049600 0x8802:61698:20000000 0x8803:61697:1500


BGP routing table entry for 1:100:172.16.10.0/24, version 16 Paths: (2 available, best #2, table CustomerA) Advertised to non peer-group peers: 10.10.10.101 Local 10.10.10.101 (metric 129) from 10.10.10.101 (10.10.10.101) Origin incomplete, metric 20537600, localpref 100, valid, internal Extended Community: RT:1:100 0x8800:32768:0 0x8801:101:537600 0x8802:32769:20000000 0x8803:32769:1500 Local 172.16.4.2 from 0.0.0.0 (10.10.10.102) Origin incomplete, metric 22073600, localpref 100, weight 32768, valid, sourced, best Extended Community: SoO:1:20 RT:1:100 0x8800:32768:0 0x8801:101:2073600 0x8802:32772:20000000 0x8803:32769:1500 PE2-AS1#show ip bgp vpnv4 vrf CustomerA 172.16.30.0 BGP routing table entry for 1:100:172.16.30.0/24, version 18 Paths: (2 available, best #2, table CustomerA) Advertised to non peer-group peers: 10.10.10.101 Local 10.10.10.101 (metric 129) from 10.10.10.101 (10.10.10.101) Origin incomplete, metric 20537600, localpref 100, valid, internal Extended Community: SoO:1:10 RT:1:100 0x8800:32768:0 0x8801:101:537600 0x8802:32769:20000000 0x8803:32769:1500 Local 172.16.4.2 from 0.0.0.0 (10.10.10.102) Origin incomplete, metric 21049600, localpref 100, weight 32768, valid, sourced, best Extended Community: SoO:1:20 RT:1:100 0x8800:32768:0 0x8801:101:1049600 0x8802:32770:20000000 0x8803:32769:1500

(3) Kiểm tra bảng định tuyến


172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks D 172.16.40.0/24 [90/3097600] via 172.16.5.2, 00:45:57, Serial0/1 D 172.16.20.0/24 [90/21561600] via 172.16.5.2, 00:28:44, Serial0/1



D 172.16.10.0/24 [90/21049600] via 172.16.3.1, 00:37:54, Serial0/0 D 172.16.4.0/30 [90/3584000] via 172.16.5.2, 00:29:46, Serial0/1 D 172.16.1.0/30 [90/21024000] via 172.16.3.1, 00:37:56, Serial0/0 D 172.16.2.0/30 [90/21536000] via 172.16.5.2, 00:28:47, Serial0/1


172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks D 172.16.30.0/24 [90/3097600] via 172.16.5.1, 00:49:26, Serial0/1 D 172.16.20.0/24 [90/21049600] via 172.16.4.1, 00:32:12, Serial0/0 D 172.16.10.0/24 [90/21561600] via 172.16.5.1, 00:41:22, Serial0/1 D 172.16.1.0/30 [90/21536000] via 172.16.5.1, 00:41:25, Serial0/1 D 172.16.2.0/30 [90/21024000] via 172.16.4.1, 00:32:15, Serial0/0 D 172.16.3.0/30 [90/3584000] via 172.16.5.1, 00:42:40, Serial0/1



Chương 5: GIAO THỨC ĐỊNH TUYẾN OSPF PE-CE

OSPF PE-CE được phát triển hỗ trợ các ISP cung cấp các dịch vụ MPLS VPN cho khách hàng khi khách hàng triển khai OSPF định tuyến bên trong site của họ, khi đó OSPF được sử dụng như giao thức định tuyến giữa các site khách hàng (inter-site routing protocol) trong một môi trường MPLS VPN.

Mô hình định tuyến OSPF truyền thống:

Miền OSPF truyền thống chia thành một backbone (area 0) và các non-backbone và các non-backbone kết nối với area 0.

Customer A thực hiện mô hình OSPF truyền thống, trong đó các non-backbone area (Area 1 và Area 2) thuộc Site 1 và Site 2 và được kết nối vào backbone area (Area 0)

Trong một môi trường MPLS VPN, các mạng của khách hàng được kết nối vào một backbone của nhà cung cấp. Trong hình trên, các area của Customer A (Area 1 và 2) kết nối vào mạng MPLS VPN của nhà cung cấp. Area 1 và Area 2 có router CE1-A và CE2-A chạy giao thức định tuyến OSPF. MP-iBGP được sử dụng giữa PE1 và PE2 để quảng bá các tuyến giữa Site 1 (Area 1) và Site 2 (Area 2). Thực hiện phân phối (redistribute) OSPF-BGP tại các router PE, PE1 và PE2. Quá trình thực hiện như sau:

(1) Mạng 172.16.10.0/24 được CE1-A quảng bá tới PE1 bằng LSA (link-state advertisement) Type 1 và Type 2.



(2) Tại PE1, tuyến 172.16.10.0/24 được redistribute vào BGP. Sau đó tuyến này được quảng bá như là một tuyến VPNv4 tới PE2.

(3) Tại PE2 địa chỉ BGP VPNv4 172.16.10.0/24 được redistribute vào OSPF. (4) Sau đó tuyến 172.16.10.0/24 được quảng bá như một tuyến OSPF với LSA

Type 5.

Do đó, loại tuyến OSPF (LSA Type) không được duy trì khi tuyến OSPF được redistribute vào BGP. Trong môi trường MPLS VPN, các nguyên tắc dịnh tuyến OSPF truyền thống vẫn được sử dụng. Tuy nhiên, một số đặc tính sau đây của tuyến OSPF external bị thay đổi khi khách hàng chuyển từ định tuyến OSPF truyền thống sang mô hình MPLS VPN:

- Các tuyến internal, không quan tâm đến cost của chúng, luôn được ưu tiên hơn tuyến external.

- Các tuyến external không được tóm tắt (summary). - Các tuyến external được flood ra mọi OSPF area. - Các tuyến External có thể dùng một loại metric khác, không thể so sánh

với OSPF cost. - Các tuyến External LSA Type 5 không được thêm vào một stub area hay

not-so-stubby area (NSSA).

Khi thực thi OSPF với MPLS VPN, khách hàng có thể có nhiều site trong Area 0. Do đó hơi khác với cấu trúc OSPF truyền thống - một backbone Area 0 và nhiều non-backbone area đượcn nối vào Area 0 này.

MPLS VPN hay khái niệm OSPF Superbackbone

Kiến trúc MPLS VPN cho định tuyến OSPF PE-CE được mở rộng để cho phép sự chuyển đổi khách hàng một cách trong suốt từ định tuyến OSPF truyền thống sang mô hình định tuyến MPLS VPN bằng cách giới thiệu một backbone khác với OSPF Area 0. Backbone này được gọi là OSPF hay MPLS VPN superbackbone.



- Các non-backbne area, Area 1 và Area 2, kết nối trực tiếp vào MPLS VPN superbackbone có chức năng như một OSPF Area 0. Do đó, không yêu cầu một Area 0 như miền OSPF truyền thống. Area 0 chỉ được yêu cầu khi router PE kết nối vào hai non-backbone area khác nhau cùng thuộc vào một OSPF domain trên một PE router.

- Các router PE, PE1 và PE2, kết nối các OSPF area trong miền khách hàng vào superbackbone, giữ vai trò là ABR (OSPF Area Border Router) cho các thiết bị trong miền OSPF của khách hàng. Các router CE, CE1 và CE2, không nhận biết được bất kỳ miền OSPF nào khác trong MPLS VPN superbackbone.

- MPLS VPN superbackbone sử dụng MP-iBGP giữa các PE. Thông tin OSPF được mang đi trong MPLS VPN backbone bằng các BGP extended community. Các extended community này được thiết lập và sử dụng bởi các router PE.

- Không có các lân cận OSPF (OSPF adjacencies) hay sự flooding trong MPLS VPN superbackbone cho các site khách hàng kết nối vào superbackbone, trừ khi sử dụng OSPF sham-link.

Các BGP Extended Community cho định tuyến OSPF PE-CE

Trong MPLS VPN superbackbone, các thuộc tính mở rộng của BGP (BGP extended attribute) sau được mang theo:

- OSPF Route Type – quảng bá thông tin loại tuyến OSPF qua MP-iBGP backbone. Hình bên dưới cho thấy thuộc tính community mở rộng OSPF route type và chi tiết OSPF route type cho mạng 172.16.20.0, 192.168.99.0 và 192.168.199.0.

- OSPF router ID – xác định router ID của PE trong VRF instance của OSPF có liên quan. Địa chỉ này không tham gia vào không gian địa chỉ của nhà cung cấp và là duy nhất trong mạng OSPF.

- OSPF domain ID – xác định miền của một địa chỉ mạng OSPF cụ thể trong MPLS VPN backbone. Mặc định, giá trị này bằng với giá trị của OSPF process ID và có thể thiết lập lại bằng lệnh: Router(config-router)#domain ID ip-address. Nếu domain ID của tuyến không trùng khớp domain ID của PE nhận, tuyến đó được chuyển thành tuyến OSPF ngoài (LSA Type 5) với



metric-type E2 trong bảng VRF. Mọi tuyến giữa các miền OSPF được nhận biết là LSA Type 5.



Quảng bá tuyến OSPF qua MPLS VPN Superbackbone

Quảng bá tuyến OSPF trong môi trường MPLS VPN không giống như trong mô hình định tuyến OSPF và phụ thuộc vào OSPF domain ID. Mặc định, OSPF domain ID bằng với process ID trên PE router. Domain ID được thiết lập trong cập nhật VPNv4 khi tuyến OSPF được redistribute vào MP-iBGP.

OSPF Domain ID giống nhau trên các router PE.

Hình sau mô tả một mạng MPLS cung cấp dịch vụ MPLS VPN cho CustomerA. Các router CE1-A và CE2-A ở các mạng 172.16.10.0/24 và 172.16.20.0/24 tại site khách hàng thuộc vào Area 1 và Area 2 trong khi kết nối PE-CE ở cả hai site thuộc vào Area 0. OSPF process ID trên cả hai router PE là 101. CE2-A là một ASBR giữa miền OSPF và hai miền RIPv2 và EIGRP (AS 101).



Quá trình thực hiện khi CE2-A gửi 172.16.20.0/24, 209.165.201.0/27 và 209.165.202.128/27 tới CE1-A:

(1) CE2-A redistribute mạng RIPv2 209.165.201.0 vào OSPF và quảng bá với LSA Type 5 có metric-type loại 1 (O E1) cho PE2-AS1. Mạng EIGRP 209.165.202.128/27 được redistribute tại CE2-A và quảng bá tới PE2-AS1 với LSA Type 5 (O E2). CE2-A cũng gửi 172.16.20.0/24 với LSA Type 3 (O IA) tới PE2-AS1.

(2) Bảng định tuyến VRF CustomerA trên PE2-AS1 nhận được tuyến 172.16.20.0/24 như là một tuyến liên vùng (O IA- OSPF Inter-Area route) với OSPF metric (cost) 74, 209.165.201.0/27 là tuyến ngoài miền loại 1 (O E1) metric 84 và tuyến 209.165.202.128/27 với metric 20.

(3) OSPF cost cho 172.16.20.0/24, 209.165.201.0/27, và 209.165.202.128/27 được sao chép vào các thuộc tính mở rộng của BGP (extended BGP attributes) như BGP MED khi OSPF được redistribute vào MP-BGP. Các tuyến 172.16.20.0, 209.165.201.0/27, và 209.165.202.128/27 được quảng bá tới PE1-AS1 qua MP-iBGP session.

(4) PE1-AS1 nhận các tuyến BGP VPNv4 172.16.20.0/24, 209.165.201.0/27 và 209.165.202.128/27 từ PE2-AS1 và thêm vào bảng BGP. OSPF metric cho các tuyến vẫn được giữ nguyên khi quảng bá quá MP-BGP backbone.

(5) Router PE nhận, PE1-AS1 redistribute các tuyến MP-BGP vào OSPF, kiểm tra domain ID, và nếu domain ID của tuyến trùng khớp domain ID trên router nhận, PE1-AS1, nó dùng LSA gốc và thuộc tính MED để phát sinh một LSA Type 3. Ở đây, domain ID trùng khớp với domain ID của PE1-AS1 nên PE1-AS1 cấu trúc lại cập nhật gốc và cập nhật metric dựa trên giao tiếp ngõ ra và quảng bá 172.126.20.0/24 là một tuyến liên vùng (O IA) tới CE1-A. 209.165.201.0/27 và 209.165.202.128/27 được quảng bá là tuyến liên miền (O E1 và O E2) tới CE1-A.



(6) CE1-A nhận 172.16.20.0 (O IA), 209.165.201.0/27 (O E1) và 209.165.202.128/27 (O E2).

SPF Domain ID khác nhau trên các router PE

Nếu process ID khác nhau trên các router PE cho các site thuộc cùng VPN, các tuyến OSPF được xem như các tuyến OSPF ngoài (OSPF LSA Type 5). Khi PE1-AS1 trong OSPF Area 1 sử dụng OSPF process ID 201 cho Site 1 thuộc VPN VPN-A, và PE2-AS1 trong OSPF Area 2 sử dụng OSPF process ID 202 cho Site 2 thuộc VPN VPN-A thì tại Site 1 và Site 2 sẽ thấy các tuyến bên ngoài (O E).

Thứ tự thực hiện khi CE2-A gửi 192.168.20.0, 192.168.99.0 và 192.168.199.0 tới CE1-A:

(1) CE2-A redistribute mạng RIPv2 192.168.99.0 vào OSPF và quảng bá nó với một LSA type 5 (O E1) tới PE2-AS1. Mạng EIGRP 192.168.199.0/24 được redistribute và quảng bá với OSPF LSA Type 5 (O E2). CE2-A cũng gửi 192.168.20.0/24 tới PE2-AS1.

(2) Bảng định tuyến VRF CustomerA trên PE2-AS1 thấy các tuyến nhận được: 192.168.20.0 với metric 74, 192.168.99.0/24 (O E2) có metric 84 và 192.168.199.0/24 có metric 20.

(3) PE2-AS1 redistribute các tuyến OSPF 192.168.20.0, 192.168.99.0, 192.168.199.0 vào MP-BGP, sao chép OSPF cost cho các tuyến này vào thuộc tính MED (multi-exit discriminator), và thiết lập community mở rộng của BGP là RT (route type) để chỉ định loại LSA từ nguồn của tuyến, cũng như thuộc tính OSPF domain ID để chỉ định chỉ số tiến trình (process number) của tiến trình OSPF nguồn (source OSPF process). OSPF RT mang thông tin vùng gốc (original area), loại LSA và metric-type của LSA loại 5.

(4) PE1-AS1 nhận các tuyến BGP VPNv4 192.168.20.0, 192.168.99.0, và 192.168.199.0 với cùng thông tin metric từ PE2-AS1. Thêm thông tin nhận được vào bảng BGP.



(5) PE2-AS1 kiểm tra thuộc tính nhận được trong tuyến, và vì domain ID của tuyến không trùng khớp với domain ID trên router nhận nên tuyến được chuyển đổi thành tuyến ngoài (LSA Type 5). Trong trường hợp này, domain ID trùng khớp với domain ID trên PE1-AS1 nên PE1-AS1 sẽ tái cấu trúc lại cập nhật gốc và cập nhật metric dựa trên các giao tiếp ngõ ra và quảng bá lại cho CE1-A.

(6) CE1-A nhận các tuyến quảng bá tới.

Ảnh hưởng của việc cấu hình OSPF Domain ID trên router PE

Cấu hình OSPF domain ID làm thay đổi hành vi (behavior) của tuyến cho các kết nối VPN với nhiều OSPF domain. Cấu hình domain ID giúp kiểm soát việc chuyển đổi LSA (cho LSA Type 3 và Type 5) giữa các OSPF domain và đường backdoor. Domain ID ngầm định là 0.0.0.0. Mỗi bảng định tuyến VPN trên một router PE tương ứng với một OSPF routing instance được cấu hình với cùng OSPF domain ID. Vì thế, Domain ID được dùng để các định các tuyến có nguồn gốc từ OSPF domain hay từ các giao thức định tuyến bên ngoài dựa trên LSA. Trong hình trên, thật khó xác định tuyến nào thuộc OSPF domian, tuyến nào thuộc miền định tuyến bên ngoài. Trong hình sau, cấu hình domain ID giống nhau trên PE1-AS1 và PE2-AS1, chúng ta có thể xác định chính xác nguồn gốc của các tuyến.

OSPF Down Bit

Lặp tuyến (routing loop) có thể xảy ra trong môi trường MPLS VPN khi các router biên phía khách hàng kết nối dạng dual-home tới mạng của nhà cung cấp. Hình bên dưới cho thấy một mạng MPLS thực thi định tuyến OSPF PE-CE cho nhiều site của Customer A VPN-A, Stie 1 và Site 2. Site 2 nằm trong OSPF Area 2 và có nhiều kết nối tới backbone của nhà cung cấp.



Việc quảng bá tuyến ở đây không thiết lập OSPF Down Bit:

(1) CE1-A gửi một LSA Type 1 hoặc LSA Type 2 tới router biên của nhà cung cấp (PE1).

(2) PE1 nhận tuyến OSPF nội vùng (intra-areaa) từ CE1-A và redistribute vào MP-BGP.

(3) PE2 nhận được và redistribute tuyến MP-BGP vào OSPF Area 2 như là một tuyến liên vùng (inter-area summary route) LSA Type 3.

(4) Tuyến tóm tắt được quảng bá qua vùng OSPF và được nhận bởi PE3, trong cùng Area 2.

(5) PE3 chọn tuyến OSPF, vì AD (administrative distance) của OSPF tốt hơn của MP-iBGP. PE3 redistribute tuyến OSPF ngược vào MP-BGP nên xảy ra routing loop.

Có thể ngăn routing loop bằng cách sử dụng OSPF Down Bit, một phần của trường option trong OSPF header.



OSPF Down Bit được sử dụng để chống routing loop:

Quá trình quảng bá tuyến khi OSPF Down Bit được thiết lập:

(1) CE1-A gửi LSA Type 1 hoặc Type 2 tới PE1.

(2) PE1 nhận tuyến OSPF nội vùng (intra-area OSPF route) từ CE1-A và redistribute vào MP-BGP.

(3) PE2 nhận được và redistribute tuyến MP-BGP đó vào OSPF Area 2 với LSA Type 3 và thiết lập OSPF Down Bit.

(4) Tuyến này được quảng bá qua OSPF area và PE3 nhận được.

(5) Khi PE3 nhận LSA Type 3 với Down Bit được thiết lập thì PE3 không redistribute lại vào MP-BGP.

OSPF Route Tag hay VPN Route Tag



Down Bit giúp ngăn lặp tuyến giữa MP-BGP và OSPF, nhưng không hiệu quả với các tuyến ngoài (external route), như khi redistribute giữa nhiều OSPF domain hay xen external route vào một vùng được kết nối dual-homed tới mạng của nhà cung cấp. PE redistribute một tuyến OSPF từ các miền OSPF khác nhau vào một miền OSPF thành các external route. Down Bit không được thiết lập vì LSA Type 5 không hỗ trợ Down Bit. Tuyến được redistribute được quảng bá qua OSPF domain.

Một router không chạy MPLS (non-MPLS router) có thể redistribute tuyến OSPF vào miền OSPF khác. Tuyến OSPF đó được quảng bá qua miền OSPF khác mà không có Down Bit. Một router PE nhận được tuyến OSPF. Khi không có Down Bit, tuyến đó lại được redistribute vào MP-BGP backbone và gây ra routing loop. Điều này được thể hiện trong hình sau với các tuyến ngoài được quảng bá vào các VPN site.

Các bước thực hiện như sau:

(1) CE2-A gửi một LSA Type 5 cho 209.165.201.0/27 tới PE2-AS1.

(2) PE2-AS1 nhận tuyến OSPF ngoài (O E1) từ CE2-A với OSPF Down Bit được thiết lập và redistribute nó vào MP-BGP.

(3) Giả sử router nhận được là PE1-AS1, vì nó được redistribute tới một miền OSPF khác (201) nên PE1-AS1 xóa OSPF Down Bit và quảng bá tuyến tới CE1-A như là một tuyến ngoài (O E1), LSA Type 5.

(4) CE1-A nhận tuyến không có thiết lập OSPF Down Bit và quảng bá external route đó tới PE3-AS1.

(5) PE3-AS1 nhận được tuyến này và redistribute trở vào MP-BGP.

(6) PE3-AS1 quảng bá tuyến này tới cho PE1-AS1 và PE2-AS1 nên có thể xảy ra routing loop.

Routing loop xảy ra cho các tuyến redistribute giữa các miền OSPF có thể được giải quyết bằng trường Tag, sử dụng các nguyên tắc redistribute BGP-OSPF chuẩn. Một tuyến không phải OSPF (non-OSPF route) được redistribute như là một external OSPF route bởi các router PE. Mặc định, trường Tag được thiết lập theo giá trị của BGP-AS. Tuyến được redistibute sẽ được quảng bá qua OSPF domain mà không có Down Bit nhưng được thiết lập trường Tag. Khi route được redistibute vào miền OSPF domain thì trường Tag cũng được quảng bá. Các router PE khác nhận được thực hiện lọc tuyến dựa trên trường Tag. Nếu trường Tag trùng khớp với chỉ số AS thì tuyến không được redistribute lại vào MP-BGP.



Cấu hình và kiểm chứng định tuyến OSPF PE-CE

Cơ đồ cấu hình để thực thi định tuyến OSPF PE-CE như sau:

� Chú ý:

Các phiên bản Cisco IOS trước 12.3(4)T, 12.0(27)S và 12.2(25)S có giới hạn 32 tiến trình riêng biệt tạo ra cho mỗi VRF để các PE có thể xác định đúng các tuyến OSPF thuộc vào tiến trình nào. Trong môi trường MPLS VPN, một tiến trình được sử dụng bởi MP-iBGP, một cho giao thức định tuyến IGP (ví dụ: OSPF), một tiến trình cho các tuyến nối trực tiếp (connected route) và một tuyến cho tuyến tĩnh (static route). Do đó, chỉ còn lại 28 tiến trình có thể được tạo cho các VRF sử dụng định tuyến OSPF PE-CE.

LAB 5-1 – Cấu hình định tuyến OSPF PE-CE

OSPF process ID giống nhau ở Customer A và khác nhau ở Customer B

Mô tả:

Mục tiêu của bài này là hiểu được cách OSPF process ID tham gia quyết định loại tuyến thấy được ở phía router biên của khách hàng chạy OSPF như thế nào.

- Mạng Customer A – Customer A có CE2-A và CE2-A trong cùng VPN-A và cùng OSPF domain. PE1-AS1 và PE2-AS1 có OSPF process ID 101 được cấu hình cho VRF CustomerA trên PE1-AS1 và PE2-AS1.

- Mạng Customer B – Customer B có CE1-B và CE2-B trong VPN-B. PE1-AS1 và PE2-AS1 có OSPF process ID là 201 và 202 cho hai CustomerB VRF.



Thực hiện:

Trước khi cấu hình, chắc chắn rằng mạng nhà cung cấp cung cấp các dịch vụ MPLS VPN cho các Site CustomerA và B. Cấu hình địa chỉ IP và xác định các VRF trên các router PE.

Ví dụ: Cấu hình VRF và các thuộc tính của nó trên router PE1-AS1 định tuyến OSPF PE-CE cho VRF CustomerA:

PE1-AS1(config)#ip vrf CustomerA PE1-AS1(config-vrf)# rd 1:100 PE1-AS1(config-vrf)# route-target both 1:100 PE1-AS1(config)#interface Serial1/0 PE1-AS1(config-if)# description connected to CE1-A PE1-AS1(config-if)# ip vrf forwarding CustomerA PE1-AS1(config-if)# ip address 172.16.1.1 255.255.255.252



Các bước cấu hình OSPF PE-CE trên các router PE:

(1) Cho phép dịnh tuyến trên VRF OSPF

Cho phép định tuyến trên VRF OSPF cho CustomerA trên PE1-AS1 và PE2-AS1:

PE1-AS1(config)#router ospf 101 vrf CustomerA PE1-AS1(config-router)# router-id 172.16.101.1 PE1-AS1(config-router)# network 172.16.0.0 0.0.255.255 area 0

PE2-AS1(config)#router ospf 101 vrf CustomerA PE2-AS1(config-router)# router-id 172.16.102.1 PE2-AS1(conig-router)# network 172.16.0.0 0.0.255.255 area 0

(2) Redistribute các tuyến OSPF vào BGP

Các tuyến OSPF nhận được từ các router CE được redistribute vào MP-iBGP. Chỉ redistribute những tuyến nội (internal routes).

PE1-AS1(config)#router bgp 1 PE1-AS1(config-router)#address-family ipv4 vrf CustomerA PE1-AS1(config-router-af)#redistribute ospf 101 vrf CustomerA match

internal external 1 external 2

PE2-AS1(config)#router bgp 1 PE2-AS1(config-router)#address-family ipv4 vrf CustomerA PE2-AS1(config-router-af)#redistribute ospf 101 vrf CustmerA match internal

external 1 external 2

(3) Redistribute MP-iBGP vào OSPF

Thực hiện redistribute các tuyến BGP VPNv4 vào lại OSPF trên các router PE.

PE1-AS1(config)#router ospf 100 vrf CustomerA PE1-AS1(config-router)# redistribute bgp 1 subnets

PE2-AS1(config)#router ospf 100 vrf CustomerA PE2-AS1(config-router)# redistribute bgp 1 subnets

Cấu hình tương tự với định tuyến VRF OSPF cho CustomerB

Cấu hình

Router P1-AS1

! hostname P1-AS1 ! ip subnet-zero ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.200 255.255.255.255 ! interface Serial0/0



description Connected to PE1-AS1 ip address 10.10.10.2 255.255.255.252 tag-switching ip clockrate 64000 ! interface Serial0/1 description Connected to PE2-AS1 ip address 10.10.10.6 255.255.255.252 tag-switching ip clockrate 64000 ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! ip classless ! call rsvp-sync ! end

Router PE1-AS1

! hostname PE1-AS1 ! ip subnet-zero ! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip vrf CustomerB rd 1:200 route-target export 1:200 route-target import 1:200 ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Loopback101 description OSPF Router ID for VRF CustomerA ip vrf forwarding CustomerA ip address 172.16.101.1 255.255.255.255 ! interface Loopback201 description OSPF Router ID for VRF CustomerB



ip vrf forwarding CustomerB ip address 192.168.201.1 255.255.255.255 ! interface Serial0/0 description Connected to P1-AS1 ip address 10.10.10.1 255.255.255.252 tag-switching ip ! interface Serial1/1 description Connected to CE1-A ip vrf forwarding CustomerA ip address 172.16.1.1 255.255.255.252 clockrate 64000 ! interface Serial1/3 description Connected to CE1-B ip vrf forwarding CustomerB ip address 192.168.1.1 255.255.255.252 ! router ospf 101 vrf CustomerA router-id 172.16.101.1 log-adjacency-changes redistribute bgp 1 subnets network 172.16.0.0 0.0.255.255 area 0 ! router ospf 201 vrf CustomerB router-id 192.168.201.1 log-adjacency-changes redistribute bgp 1 subnets network 192.168.0.0 0.0.255.255 area 1 ! router ospf 1 router-id 10.10.10.101 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended no auto-summary exit-address-family ! address-family ipv4 vrf CustomerB



redistribute ospf 201 match internal external 1 external 2 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf CustomerA redistribute ospf 101 match internal external 1 external 2 no auto-summary no synchronization exit-address-family ! ip http server ip classless ! end

Router PE2-AS1

! hostname PE2-AS1 ! ip subnet-zero ! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip vrf CustomerB rd 1:200 route-target export 1:200 route-target import 1:200 ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Loopback101 description OSPF Router ID for VRF CustomerA ip vrf forwarding CustomerA ip address 172.16.102.1 255.255.255.255 ! interface Loopback202 description OSPF Router ID for VRF CustomerB ip vrf forwarding CustomerB ip address 192.168.202.1 255.255.255.255 ! interface Serial0/1



description Connected to P1-AS1 ip address 10.10.10.5 255.255.255.252 tag-switching ip ! interface Serial1/0 description Connected to CE2-A ip vrf forwarding CustomerA ip address 172.16.2.1 255.255.255.252 clockrate 64000 ! interface Serial1/2 description Connected to CE2-B ip vrf forwarding CustomerB ip address 192.168.2.1 255.255.255.252 clockrate 64000 ! router ospf 101 vrf CustomerA router-id 172.16.102.1 log-adjacency-changes redistribute bgp 1 subnets network 172.16.0.0 0.0.255.255 area 0 ! router ospf 202 vrf CustomerB router-id 192.168.202.1 log-adjacency-changes redistribute bgp 1 subnets network 192.168.0.0 0.0.255.255 area 2 ! router ospf 1 router-id 10.10.10.102 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended no auto-summary exit-address-family ! address-family ipv4 vrf CustomerB redistribute ospf 202 match internal external 1 external 2 no auto-summary no synchronization



exit-address-family ! address-family ipv4 vrf CustomerA redistribute ospf 101 match internal external 1 external 2 no auto-summary no synchronization exit-address-family ! ip http server ip classless ! end

Router CE1-A

! hostname CE1-A ! ip subnet-zero ! interface Ethernet0/0 description VPN-A Site 1 network ip address 172.16.10.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE1-AS1 ip address 172.16.1.2 255.255.255.252 no fair-queue ! router ospf 101 log-adjacency-changes network 172.16.1.0 0.0.0.255 area 0 network 172.16.10.0 0.0.0.255 area 1 ! ip classless ! end

Router CE2-A

! hostname CE2-A ! ip subnet-zero ! interface Loopback0 description RIPv2 network ip address 209.165.201.1 255.255.255.224 ! interface Loopback1



description EIGRP network ip address 209.165.202.129 255.255.255.224 ! interface Ethernet0/0 description VPN-A Site 2 network ip address 172.16.20.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE2-AS1 ip address 172.16.2.2 255.255.255.252 no fair-queue ! router eigrp 1 network 209.165.202.0 no auto-summary ! router ospf 101 log-adjacency-changes redistribute eigrp 1 subnets redistribute rip metric-type 1 subnets network 172.16.2.0 0.0.0.255 area 0 network 172.16.20.0 0.0.0.255 area 2 ! router rip version 2 redistribute ospf 101 match internal external 1 external 2 network 209.165.201.0 no auto-summary ! ip classless ! end

Router CE1-B

! hostname CE1-B ! ip subnet-zero ! interface FastEthernet0/0 description VPN-B Site 1 network ip address 192.168.10.1 255.255.255.0 duplex auto speed auto no keepalive ! interface Serial0/0 description Connected to PE1-AS1



ip address 192.168.1.2 255.255.255.252 clockrate 64000 no fair-queue ! router ospf 201 log-adjacency-changes network 192.168.1.0 0.0.0.255 area 1 network 192.168.10.0 0.0.0.255 area 1 ! ip classless ! end

Router CE2-B

! hostname CE2-B ! ip subnet-zero ! interface Loopback0 description RIPv2 network ip address 192.168.99.1 255.255.255.0 ! interface Loopback1 description EIGRP network ip address 192.168.199.1 255.255.255.0 ! interface Ethernet0/0 description VPN-B site 2 network ip address 192.168.20.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE2-AS1 ip address 192.168.2.2 255.255.255.252 no fair-queue ! router eigrp 1 redistribute ospf 202 metric 1500 1 255 1 1500 match internal external 1 external 2 network 192.168.199.0 no auto-summary ! router ospf 202 log-adjacency-changes redistribute eigrp 1 subnets redistribute rip metric-type 1 subnets network 192.168.2.0 0.0.0.255 area 2 network 192.168.20.0 0.0.0.255 area 2 !



router rip version 2 redistribute ospf 202 metric 1 match internal external 1 external 2 network 192.168.99.0 no auto-summary ! ip classless ! end

Kiểm tra:

Các bước kiểm tra định tuyến OSPF PE-CE như sau:

(1) Kiểm tra quan hệ neighbor và adjacency giữa các router PE và các router biên CE:

PE1-AS1#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface 10.10.10.200 0 FULL/ - 00:00:37 10.10.10.2 Serial0/0 192.168.10.1 0 FULL/ - 00:00:35 192.168.1.2 Serial1/3 172.16.10.1 0 FULL/ - 00:00:30 172.16.1.2 Serial1/1


Neighbor ID Pri State Dead Time Address Interface 10.10.10.200 0 FULL/ - 00:00:31 10.10.10.6 Serial0/1 192.168.199.1 0 FULL/ - 00:00:38 192.168.2.2 Serial1/2 209.165.202.129 0 FULL/ - 00:00:35 172.16.2.2 Serial1/0

(2) Kiểm tra việc quảng bá tuyến cho CustomerA

Bảng định tuyến VRF cho CustomerA nhận được các tuyến do CE2-A quảng bá tới.

PE2-AS1#show ip route vrf CustomerA ospf 101

172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks O IA 172.16.20.0/24 [110/791] via 172.16.2.2, 00:44:34, Serial1/0 209.165.201.0/27 is subnetted, 1 subnets O E1 209.165.201.0 [110/801] via 172.16.2.2, 00:44:34, Serial1/0 209.165.202.0/27 is subnetted, 1 subnets O E2 209.165.202.128 [110/20] via 172.16.2.2, 00:44:34, Serial1/0

Các tuyến OSPF này được redistribute vào MP-iBGP và các metric của tuyến OSPF được sao chép vào các thuộc tính mở rộng của BGP như các BGP MED. Sau đó các tuyến này được quảng bá tới PE1-AS1 bằng MP-iBGP session.

PE2-AS1#show ip bgp vpn vrf CustomerA

BGP table version is 33, local router ID is 10.10.10.102

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete



Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 (default for vrf CustomerA) *>i172.16.1.0/30 10.10.10.101 0 100 0 ? *> 172.16.2.0/30 0.0.0.0 0 32768 ? *>i172.16.10.0/24 10.10.10.101 791 100 0 ? *> 172.16.20.0/24 172.16.2.2 791 32768 ? *>i172.16.101.1/32 10.10.10.101 0 100 0 ? *> 172.16.102.1/32 0.0.0.0 0 32768 ? *> 209.165.201.0/27 172.16.2.2 801 32768 ? *> 209.165.202.128/27 172.16.2.2 20 32768 ?

PE2-AS1#show ip bgp vpnv4 all 172.16.20.0

BGP routing table entry for 1:100:172.16.20.0/24, version 13 Paths: (1 available, best #1, table CustomerA) Advertised to non peer-group peers: 10.10.10.101 Local 172.16.2.2 from 0.0.0.0 (10.10.10.102) Origin incomplete, metric 791, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 OSPF DOMAIN ID:0.0.0.101 OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.102.1:0

PE2-AS1#show ip bgp vpnv4 vrf CustomerA

BGP table version is 33, local router ID is 10.10.10.102 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 (default for vrf CustomerA) *>i172.16.1.0/30 10.10.10.101 0 100 0 ? *> 172.16.2.0/30 0.0.0.0 0 32768 ? *>i172.16.10.0/24 10.10.10.101 791 100 0 ? *> 172.16.20.0/24 172.16.2.2 791 32768 ? *>i172.16.101.1/32 10.10.10.101 0 100 0 ? *> 172.16.102.1/32 0.0.0.0 0 32768 ? *> 209.165.201.0/27 172.16.2.2 801 32768 ? *> 209.165.202.128/27 172.16.2.2 20 32768 ?

CE1-A#show ip route ospf

172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks O IA 172.16.20.0/24 [110/855] via 172.16.1.1, 00:41:36, Serial0/0 O IA 172.16.2.0/30 [110/65] via 172.16.1.1, 00:41:36, Serial0/0 O 172.16.101.1/32 [110/65] via 172.16.1.1, 01:05:21, Serial0/0 O IA 172.16.102.1/32 [110/65] via 172.16.1.1, 00:41:36, Serial0/0 209.165.201.0/27 is subnetted, 1 subnets



O E1 209.165.201.0 [110/865] via 172.16.1.1, 00:41:36, Serial0/0 209.165.202.0/27 is subnetted, 1 subnets O E2 209.165.202.128 [110/20] via 172.16.1.1, 00:41:36, Serial0/0

(3) Kiểm tra việc quảng bá tuyến cho CustomerB

PE2-AS1#show ip route vrf CustomerB ospf 202

O E2 192.168.199.0/24 [110/20] via 192.168.2.2, 00:44:06, Serial1/2 O E1 192.168.99.0/24 [110/801] via 192.168.2.2, 00:44:06, Serial1/2 O 192.168.20.0/24 [110/791] via 192.168.2.2, 00:44:06, Serial1/2

PE2-AS1#show ip bgp vpnv4 all | begin 192.168.20.0

*> 192.168.20.0 192.168.2.2 791 32768 ? *> 192.168.99.0 192.168.2.2 801 32768 ? *> 192.168.199.0 192.168.2.2 20 32768 ?

PE1-AS1#show ip bgp vpnv4 all | begin 192.168.20.0

*>i192.168.20.0 10.10.10.102 791 100 0 ? *>i192.168.99.0 10.10.10.102 801 100 0 ? *>i192.168.199.0 10.10.10.102 20 100 0 ?

CE1-B#show ip route ospf

O E2 192.168.199.0/24 [110/20] via 192.168.1.1, 00:12:06, Serial0/0 192.168.201.0/32 is subnetted, 1 subnets O 192.168.201.1 [110/65] via 192.168.1.1, 00:35:15, Serial0/0 O E2 192.168.99.0/24 [110/801] via 192.168.1.1, 00:12:06, Serial0/0 O E2 192.168.20.0/24 [110/791] via 192.168.1.1, 00:12:06, Serial0/0 192.168.202.0/32 is subnetted, 1 subnets O E2 192.168.202.1 [110/1] via 192.168.1.1, 00:12:06, Serial0/0 192.168.2.0/30 is subnetted, 1 subnets O E2 192.168.2.0 [110/1] via 192.168.1.1, 00:12:06, Serial0/0

OSPF Sham-Link

Hình dưới mô tả mạng của ISP cung cấp các dịch vụ MPLS VPN cho các Customer A thuộc cùng VPN-A có sử dụng Backdoor Link.



Customer A có 4 Site trong VPN-A. Các site đều thuộc Area 0. Site 3 và Site 4 được kết nối với nhau bằng một được backdoor link băng thông thấp (512 kbps). Backdoor link này cung cấp kết nối giữa Site 3 và Site 4 khi kết nối đến backbone của nhà cung cấp bị sự cố (down hoặc disconnected). Các site này cũng kết nối tới BGP-based MPLS VPN backbone của nhà cung cấp. Kiểu tích hợp này có thể xem là một dạng định tuyến kém tối ưu (suboptimal routing) như hình sau:

Trình tự thực hiện khi CE4-A quảng bá 172.16.40.0/24 tới cho CE3-A:

(1) CE4-A gửi một LSA Type 1 cho 172.16.40.0/24 tới PE2-AS1 và CE3-A.



(2) PE2-AS1 nhận 172.16.40.0/4 là một intra-area route, và redistribute vào MP-BGP.

(3) PE1-AS1 redistribute 172.16.40.0/24 vào OSPF và quảng bá 172.16.40.0/4 là một intra-area route tới CE3-A.

(4) CE3-A nhận được hai inter-area route 172.16.40.0/24 từ PE1-AS1 và một intra-area route từ CE4-A. Vì intra-area route được ưu tiên hơn nên được thêm vào cơ sở dữ liệu OSPF (OSPF database).

Trình tự này cùng xảy ra với 172.16.30.0/24 khi nó được CE2-A quảng bá đi. Do đó, các gói dữ liệu xuất phát từ 172.16.30.0 (Site 3) tới 172.16.40.0 (Site 4) sẽ qua backdoor link. Tương tự cho các luồng lưu lượng bắt nguồn từ 172.16.10.0 (Site 1) tới 172.16.20.0 (Site 2) vì bất kỳ tuyến liên quan nào từ MPLS VPN backbone sẽ là các inter-area route và intra-area route thì được ưu tiên hơn. Vì thế, việc chuyển tiếp lưu lượng dạng này được gọi là suboptimal vì backdoor link có băng thông thấp và được dùng để dự phòng (backup). Bên dưới cho thấy đường chuyển tiếp lưu lượng trong mạng MPLS VPN sử dụng backdoor link (không sham link).

Có thể tránh trường hợp này bằng cách sử dụng một sham-link. Một sham-link là một kết nối luận lý (logical link) thuộc về nội vùng (intra-area) nhưng không được mang theo bởi BGP-based superbackbone. Hai router PE sẽ là endpoint của sham-link. Chúng sẽ thiết lập một OSPF adjacency đi qua và floot các intra-area LSA qua kết nối này. Sham-link được xem là một mạch ảo theo yêu cầu (DC – demand circuit) của OSPF nhằm giảm luồng lưu lượng qua sham-link. Điều này giúp tránh việc các LSA được floot định kỳ qua sham-link. Hình sau mô tả một sham-link:



CE4-A gửi 172.16.40.0/24 vớ LSA Type 1 tới CE3-A, sau đó LSA này được quảng bá tới PE1-AS1. PE1-AS1 nhận được OSPF-LSA Type 1 từ CE4-A qua CE3-A và từ PE2-AS1 qua OSPF sham-link. OSPF sham-link được đối xử như một kết nối nội vùng (intra-area link) giữa PE1-AS1 và PE2-AS1. Cost của sham-link có thể được cấu hình sao cho thấp hơn cost của backup link giữa CE3-A và CE4-A. Do đó PE2-AS1 redistribute tuyến 172.16.40.0/24 vào MP-BGP vì tuyến OSPF này không được nhận qua một sham-link từ PE1-AS1. PE1-AS1 cũng không redistribute tuyến này vào MP-iBGP vì nó không được nhận từ PE2-AS1 qua OSPF sham-link. PE1-AS1 cài đặt tuyến OSPF nhận được từ sham-link vào bảng định tuyến VRF của nó. LSA cho tuyến 172.16.40.0/24 được quảng bá đến Site 4 để cho phép Site 3 chọn đường đi tốt nhất. Khi đó, các gói nhận được từ Site 4 sẽ được định tuyến qua MPLS VPN backbone và sử dụng kết nối băng thông cao. Như vậy, CE3-A tại Site 3 cũng chọn sham-link là đường đi tốt nhất đến 172.16.40.0/24. Vì thế luồng lưu lượng giữa giữa Site 3 và Site 4 được định tuyến tối ưu qua sham-link giữa PE1-AS1 và PE2-AS1.

Sơ đồ cấu hình cho OSPF Sham-Link

LAB 5-2—OSPF Sham-Links

Mô tả



Thực hiện

Cấu hình địa chỉ ip và định nghĩa các VRF trên các PE.

Cấu hình OSPF Sham-link theo các bước sau:

(1) Tạo các đầu cuối (endpoint) của sham-link

Tạo các giao tiếp loopback trên mỗi router PE và gắn kết nó vào VRF CustomerA của VPN. Địa chỉ loopback là một địa chỉ trong không gian địa chỉ của VPN, không được là không gian địa chỉ của nhà cung cấp dịch vụ MPLS VPN vì sham-link là một kết nối của khách hàng (CustomerA).

Tạo endpoint thực hiện trên PE1-AS1 và PE2-AS1 như sau:

PE1-AS1(config)#interface Loopback101 PE1-AS1(config-if)# description sham-link Endpoint on PE1-AS1 PE1-AS1(config-if)# ip vrf forwarding Cust_A PE1-AS1(config-if)# ip address 172.16.101.1 255.255.255.255 PE2-AS1(config)#interface Loopback101 PE2-AS1(config-if)# description sham-link Endpoint on PE2-AS1 PE2-AS1(config-if)# ip vrf forwarding Cust_A PE2-AS1(config-if)# ip address 172.16.102.1 255.255.255.255

(2) Redistribute endpoint vào MP-BGP

PE1-AS1(config)#router bgp 1 PE1-AS1(config-router)#address-family ipv4 vrf Cust_A PE1-AS1(config-router-af)# redistribute connected PE2-AS1(config)#router bgp 1 PE2-AS1(config-router)#address-family ipv4 vrf Cust_A



PE2-AS1(config-router-af)# redistribute connected

(3) Cho phép sham-link qua tiến trình OSPF VRF

PE1-AS1(config)#router ospf 101 vrf Cust_A PE1-AS1(config-router)#area 0 sham-link 172.16.101.1 172.16.102.1 cost 1

PE2-AS1(config)#router ospf 101 vrf Cust_A PE2-AS1(config-router)#area 0 sham-link 172.16.102.1 172.16.101.1 cost 1

Cấu hình

Router P1-AS1

! hostname P1-AS1 ! ip subnet-zero ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.200 255.255.255.255 ! interface Serial0/0 description Connected to PE1-AS1 ip address 10.10.10.2 255.255.255.252 tag-switching ip clockrate 64000 ! interface Serial0/1 description Connected to PE2-AS1 ip address 10.10.10.6 255.255.255.252 tag-switching ip clockrate 64000 ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! ip http server ip classless ! end

Router PE1-AS1

!

hostname PE1-AS1

! ip subnet-zero ! !



! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Loopback101 description Sham-link Endpoint on PE1-AS1 ip vrf forwarding CustomerA ip address 172.16.101.1 255.255.255.255 ! interface Serial0/0 description Connected to P1-AS1 ip address 10.10.10.1 255.255.255.252 tag-switching ip ! interface Serial1/1 description Connected to CE1-A ip vrf forwarding CustomerA ip address 172.16.1.1 255.255.255.252 clockrate 64000 ! interface Serial1/3 description Connected to CE3-A ip vrf forwarding CustomerA ip address 172.16.3.1 255.255.255.252 ! router ospf 101 vrf CustomerA router-id 172.16.101.1 log-adjacency-changes area 0 sham-link 172.16.101.1 172.16.102.1 redistribute bgp 1 subnets network 172.16.1.0 0.0.0.255 area 0 network 172.16.3.0 0.0.0.255 area 0 ! router ospf 1 router-id 10.10.10.101 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.102 remote-as 1



neighbor 10.10.10.102 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community both no auto-summary exit-address-family ! address-family ipv4 vrf CustomerA redistribute connected redistribute ospf 101 match internal external 1 external 2 no auto-summary no synchronization exit-address-family ! ip http server ip classless ! end

Router PE2-A

! hostname PE2-AS1 ! ip vrf CustomerA rd 1:100 route-target export 1:100 route-target import 1:100 ! ip cef mpls ldp logging neighbor-changes ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Loopback101 description Sham-link Endpoint on PE2-AS1 ip vrf forwarding CustomerA ip address 172.16.102.1 255.255.255.255 ! interface Serial0/1 description Connected to P1-AS1 ip address 10.10.10.5 255.255.255.252 tag-switching ip ! interface Serial1/0 description Connected to CE2-A ip vrf forwarding CustomerA ip address 172.16.2.1 255.255.255.252



clockrate 64000 ! interface Serial1/2 description Connected to CE4-A ip vrf forwarding CustomerA ip address 172.16.4.1 255.255.255.252 clockrate 64000 ! router ospf 101 vrf CustomerA router-id 172.16.102.1 log-adjacency-changes area 0 sham-link 172.16.102.1 172.16.101.1 redistribute bgp 1 subnets network 172.16.2.0 0.0.0.255 area 0 network 172.16.4.0 0.0.0.255 area 0 ! router ospf 1 router-id 10.10.10.102 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community both no auto-summary exit-address-family ! address-family ipv4 vrf CustomerA redistribute connected redistribute ospf 101 match internal external 1 external 2 no auto-summary no synchronization exit-address-family ! ip classless ! end

Router CE1-A

! hostname CE1-A ! mpls ldp logging neighbor-changes



! interface Ethernet0/0 description VPN-A Site 1 network ip address 172.16.10.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE1-AS1 ip address 172.16.1.2 255.255.255.252 no fair-queue ! router ospf 101 log-adjacency-changes network 172.16.0.0 0.0.255.255 area 0 ! ip http server ip classless ! end

Router CE2-A

! hostname CE2-A ! interface Ethernet0/0 description VPN-A CustomerA Site 2 network ip address 172.16.20.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE2-AS1 ip address 172.16.2.2 255.255.255.252 ! router ospf 101 log-adjacency-changes network 172.16.0.0 0.0.255.255 area 0 ! ip classless ! end

Router CE3-A

! hostname CE3-A ! interface FastEthernet0/0 description VPN-A CustomerA Site 3 network ip address 172.16.30.1 255.255.255.0



duplex auto speed auto no keepalive ! interface Serial0/0 description Connected to PE1-AS1 ip address 172.16.3.2 255.255.255.252 clockrate 64000 no fair-queue ! interface Serial0/1 description Sham-link, connected to CE4-A bandwidth 512 ip address 172.16.5.1 255.255.255.252 ! router ospf 101 log-adjacency-changes network 172.16.0.0 0.0.255.255 area 0 ! ip classless ! end

Router CE4-A

! hostname CE4-A ! interface Ethernet0/0 description VPN-A CustomerA Site 4 network ip address 172.16.40.1 255.255.255.0 half-duplex no keepalive ! interface Serial0/0 description Connected to PE2-AS1 ip address 172.16.4.2 255.255.255.252 no fair-queue ! interface Serial0/1 description Sham-link, connected to CE3-A bandwidth 512 ip address 172.16.5.2 255.255.255.252 clockrate 64000 ! router ospf 101 log-adjacency-changes network 172.16.0.0 0.0.255.255 area 0 ! ip classless !



end

Kiểm tra hoạt động của Sham-link

PE1-AS1#show ip route vrf CustomerA

Routing Table: CustomerA Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 11 subnets, 3 masks O 172.16.40.0/24 [110/792] via 10.10.10.102, 00:33:15 O 172.16.30.0/24 [110/782] via 172.16.3.2, 00:33:59, Serial1/3 O 172.16.20.0/24 [110/792] via 10.10.10.102, 00:33:15 O 172.16.10.0/24 [110/791] via 172.16.1.2, 00:33:59, Serial1/1 O 172.16.4.0/30 [110/782] via 10.10.10.102, 00:33:45 O 172.16.5.0/30 [110/976] via 172.16.3.2, 00:33:59, Serial1/3 C 172.16.1.0/30 is directly connected, Serial1/1 O 172.16.2.0/30 [110/782] via 10.10.10.102, 00:33:46 C 172.16.3.0/30 is directly connected, Serial1/3 C 172.16.101.1/32 is directly connected, Loopback101 B 172.16.102.1/32 [200/0] via 10.10.10.102, 00:34:17


172.16.0.0/16 is variably subnetted, 11 subnets, 3 masks O 172.16.40.0/24 [110/791] via 172.16.4.2, 00:42:24, Serial1/2 O 172.16.30.0/24 [110/783] via 10.10.10.101, 00:42:24 O 172.16.20.0/24 [110/791] via 172.16.2.2, 00:42:24, Serial1/0 O 172.16.10.0/24 [110/792] via 10.10.10.101, 00:42:24 O 172.16.5.0/30 [110/976] via 172.16.4.2, 00:42:24, Serial1/2 O 172.16.1.0/30 [110/782] via 10.10.10.101, 00:42:24 O 172.16.3.0/30 [110/782] via 10.10.10.101, 00:42:24


172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks O 172.16.40.0/24 [110/205] via 172.16.5.2, 00:17:34, Serial0/1 O 172.16.20.0/24 [110/856] via 172.16.3.1, 00:17:34, Serial0/0 O 172.16.10.0/24 [110/855] via 172.16.3.1, 00:17:34, Serial0/0 O 172.16.4.0/30 [110/259] via 172.16.5.2, 00:17:34, Serial0/1 O 172.16.1.0/30 [110/845] via 172.16.3.1, 00:17:34, Serial0/0 O 172.16.2.0/30 [110/846] via 172.16.3.1, 00:17:34, Serial0/0

CE4-A#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area



N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks C 172.16.40.0/24 is directly connected, Ethernet0/0 O 172.16.30.0/24 [110/196] via 172.16.5.1, 00:26:15, Serial0/1 O 172.16.20.0/24 [110/855] via 172.16.4.1, 00:26:15, Serial0/0 O 172.16.10.0/24 [110/856] via 172.16.4.1, 00:26:15, Serial0/0 C 172.16.4.0/30 is directly connected, Serial0/0 C 172.16.5.0/30 is directly connected, Serial0/1 O 172.16.1.0/30 [110/846] via 172.16.4.1, 00:26:15, Serial0/0 O 172.16.2.0/30 [110/845] via 172.16.4.1, 00:26:16, Serial0/0 O 172.16.3.0/30 [110/259] via 172.16.5.1, 00:26:16, Serial0/1


Type escape sequence to abort. Tracing the route to 172.16.40.1 1 172.16.5.2 16 msec 12 msec *


Type escape sequence to abort. Tracing the route to 172.16.20.1 1 172.16.1.1 16 msec 16 msec 16 msec 2 10.10.10.2 [MPLS: Labels 17/23 Exp 0] 153 msec 153 msec 152 msec 3 172.16.2.1 [MPLS: Label 23 Exp 0] 88 msec 88 msec 88 msec 4 172.16.2.2 56 msec 56 msec *


Type escape sequence to abort. Tracing the route to 172.16.40.1 1 172.16.1.1 16 msec 16 msec 16 msec 2 10.10.10.2 [MPLS: Labels 17/22 Exp 0] 152 msec 152 msec 152 msec 3 172.16.4.1 [MPLS: Label 22 Exp 0] 88 msec 88 msec 88 msec 4 172.16.4.2 56 msec 56 msec *

PE1-AS1#show ip ospf sham-links

Sham Link OSPF_SL0 to address 172.16.102.1 is up Area 0 source address 172.16.101.1 Run as demand circuit DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Hello due in 00:00:03 Adjacency State FULL (Hello suppressed)



Index 3/3, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec


Neighbor ID Pri State Dead Time Address Interface 10.10.10.200 0 FULL/ - 00:00:34 10.10.10.2 Serial0/0 172.16.30.1 0 FULL/ - 00:00:39 172.16.3.2 Serial1/3 172.16.10.1 0 FULL/ - 00:00:30 172.16.1.2 Serial1/1 172.16.102.1 0 FULL/ - - 172.16.102.1 OSPF_SL0


172.16.0.0/16 is variably subnetted, 11 subnets, 3 masks O 172.16.40.0/24 [110/792] via 10.10.10.102, 00:35:18 O 172.16.30.0/24 [110/782] via 172.16.3.2, 00:36:02, Serial1/3 O 172.16.20.0/24 [110/792] via 10.10.10.102, 00:35:18 O 172.16.10.0/24 [110/791] via 172.16.1.2, 00:36:02, Serial1/1 O 172.16.4.0/30 [110/782] via 10.10.10.102, 00:35:47 O 172.16.5.0/30 [110/976] via 172.16.3.2, 00:36:02, Serial1/3 O 172.16.2.0/30 [110/782] via 10.10.10.102, 00:35:47



CE4-A#show ip route




Chương 6: KỸ THUẬT LƯU LƯỢNG TRONG MPLS

Khái ni ệm về kỹ thuật lưu lượng (Traffic Engineering)

Khi đối mặt với sự phát triển và mở rộng mạng có hai vấn đề kỹ thuật cần quan tâm: kỹ thuật mạng (network engineering) và kỹ thuật lưu lượng (traffic engineering). Kỹ thuật mạng là tổ chức mạng phù hợp với lưu lượng. Ban đầu phải có sự dự đoán tốt nhất về lưu lượng trên mạng để sử dụng các mạch và các thiết bị mạng (router, switch, …) thích hợp. Kỹ thuật mạng phải đảm bảo hiệu quả về sau này vì thời gian lắp đặt mạng có thể diễn ra lâu dài. Kỹ thuật lưu lượng là thao tác trên lưu lượng để phù hợp với mạng. Dù có cố gắng đến đâu thì lưu lượng mạng cũng không bao giờ được đáp ứng hoàn toàn (100%) so với dự tính. Giữa thập niên 90 sự tăng trưởng lưu lượng vượt quá mọi dự tính và không thể nâng cấp mạng kịp thời được. Đôi khi một sự kiện nổi bật (sự kiện thể thao, vụ bê bối chính trị, một trang web phổ biến,…) làm đầy lưu lượng trên mạng, điều này không thể tính toán trước được. Do đó có thể tại một nơi nhu cầu băng thông quá nhiều nhưng đồng thời có các đường liên kết (link) khác chưa được sử dụng. Kỹ thuật lưu lượng là một “nghệ thuật” chuyển lưu lượng từ các liên kết bị đầy sang các liên kết rỗi. Kỹ thuật lưu lượng có thể được bổ sung : IP metric trên giao tiếp,chạy một mắc lưới ATM PVC và xác định lại đường PVC dựa trên yêu cầu về lưu lượng đi qua nó. Kỹ thuật lưu lượng trong MPLS nhằm đạt đến kỹ thuật điều khiển lưu lượng hướng kết nối tốt nhất và kết hợp với định tuyến IP.

Kỹ thuật lưu lượng trước MPLS

Ta sẽ xem xét các kỹ thuật lưu lượng của IP và ATM:

Kỹ thuật lưu lượng IP thì phổ biến nhưng chất lượng khá kém. Cách điều khiển chủ yếu của IP là thay đổi chi phí trên một liên kết cụ thể. Việc điều khiển lưu lượng chỉ dựa trên một con đường nó sẽ đi tới – không hợp lý. Ngược lại, ATM để bạn thay thế các PVC trên mạng từ nguồn đến đích của sự lưu thông. Nghĩa là đạt được quyền điều khiển tốt hơn trên các luồng lưu lượng. Vài nhà cung cấp dịch vụ (ISP) lớn trên thế giới sử dụng ATM để quản lý lưu lượng trên mạng của họ bằng cách xây dựng mạng lưới đầy đủ các ATM PVC giữa một tập các router, tái định kích thước và vị trí các ATM PVC đó một cách định kỳ dựa trên thông tin lưu lượng do các router cung cấp.

Bài toán con cá

Trong mạng IP: Trong hình có hai con đường đi từ R2 đến R6 : R2 � R5 � R6 R2 � R3 � R4 � R6



Vì các liên kết này có cùng chi phí (cost = 15), theo chuyển tiếp đích thông thường, tất cả các gói đến từ R1 và R7 được ra ở cùng giao tiếp của R2 để tới R5, vì chi phí (cost) của đường phía trên thấp hơn ở dưới. Tất cả các liên kết trong hình có băng thông 150 Mbps, R1 gửi 90 Mbps và R7 gửi 100 Mbps. Lúc này nảy sinh vấn đề: R2 cố gắng chuyển 190 Mbps qua đường (pipe) 150 Mbps. Nghĩa là R2 phải huỷ 40 Mbps cho phù hợp với đường truyền. Việc chuyển tiếp hướng đích (destination base forwarding) không thể giải quyết vấn đề này. Chỉ có thể huỷ bỏ liên kết hoặc chuyển chi phí liên kết để con đường ngắn lẫn đường dài đều có cùng chi phí nhằm giảm nhẹ vấn đề. Nhưng chỉ áp dụng được trên mạng nhỏ.

Trong mạng ATM:

Xây dựng hai PVC từ R2 đến R6 và thiết lập cho chúng cùng chi phí. Vì R2 có hai con đường đến R6 nên sẽ sử dụng cả hai con đường để mang một lượng dữ liệu hợp lý. Cơ chế chia tải có thể thay đổi đa dạng nhưng thông thường cân bằng tải trên nguồn và đích của CEF (CEF 's per-source-destination load blancing) sử dụng cả hai con đường theo cách cân bằng thô (roughly). Xây dựng hai con đường có cùng chi phí là giải pháp mềm dẻo hơn thay đổi chi phí liên kết. Trong mạng ATM các thiết bị khác nối đến mạng không ảnh hưởng đến bất kỳ sự thay đổi nào của metric. Điều này cho thấy khả năng điều khiển lưu lượng của ATM tốt hơn của IP.

Giải quyết bài toán con cá bằng MPLS TE:

Có ba điểm khác biệt về kỹ thuật lưu lượng giữa ATM và MPLS:

- MPLS TE chuyển tiếp gói (packet); ATM sử dụng tế bào (Cell). - ATM yêu cầu mạng lưới đầy đủ các tuyến lân cận (routing adjacenies); MPLS

không cần.



- Trong ATM, công nghệ lõi không thể thấy các router trên biên của mạng; MPLS thấy được nhờ các giao thức định tuyến IP quảng cáo (advertise) thông tin của nó.

Kỹ thuật lưu lượng với MPLS

MPLS TE kết hợp khả năng điều khiển lưu lượng của ATM với sự mềm dẻo của IP và sự khác nhau của các lớp dịch vụ. MPLS cho phép xây dựng các con đường chuyển nhãn (LSP - Label Switch Path) trong mạng để giảm lưu lượng chuyển tiếp. MPLS TE (có thể gọi là đường hầm điều khiển lưu lượng - TE Tunnel) dùng một đường hầm TE điều khiển lưu lượng trên đường đến một đích cụ thể. Phương pháp này mềm dẻo hơn kỹ thuật lưu lượng chuyển tiếp chỉ dựa trên địa chỉ đích. MPLS tránh được flooding O(N2) và O(N3). MPLS TE sử dụng cơ chế gọi là định tuyến động (autoroute) để xây dựng bảng định tuyến bằng MPLS TE LSP mà không cần mạng lưới đầy đủ các tuyến láng giềng (neighbor). MPLS TE dự trữ băng thông khi xây dựng LSP. Ở đây giới thiệu khái niệm tài nguyên tiêu thụ (consumable resource). Khi LSP được thêm vào mạng chúng có thể tìm ra con đường có băng thông được lưu trữ sẵn. MPLS bắt buộc có sự dự trữ của mặt phẳng điều khiển, nghĩa là nếu một LSR dự trữ 10Mb và gửi đến nó 100Mb trên LSP đó, mạng sẽ thử phân chia 100 Mb đó trừ khi lưu lượng ở nguồn đã bị kỹ thuật QoS ràng buộc.

Khi nghiên cứu về kỹ thuật lưu lượng ta quan tâm đến ba vấn đề chính: (1) Sự phân phối thông tin (Information distribution): Cách các bộ định tuyến

nhận diện ra mạng và các tài nguyên nào đã sẵn sàng. (2) Tính toán và thiết lập tuyến – (Path calculation and setup): Cách các bộ định

tuyến quyết định tạo các đường hầm TE, và cách xây dựng và duy trì các đường hầm TE này một cách chính xác. (3) Chuyển tiếp lưu lượng vào một đường hầm – (Forwarding traffic down a

tunnel): Sau khi đường hầm được xây dựng thì sử dụng nó như thế nào?

Cấu hình MPLS TE

Để có thể khởi động kỹ thuật lưu lượng MPLS, mạng cần có các điều kiện sau:

Cài đặt hệ điều hành Cisco (Cisco IOS) có hỗ trợ Kỹ thuật lưu lượng MPLS. Trong mạng cho phép CEF (Cisco Express Forwarding). Một giao thức định tuyến trạng thái liên kết (OSPF hoặc IS-IS) cũng như giao thức cổng nội IGP (Interior Gateway Protocol). Kỹ thuật lưu lượng được phép trên toàn bộ router. Một giao diện loopback (mặt nạ 255.255.255.255) sử dụng như MPLS Traffic Engineering router ID (RID). Cấu hình đường hầm TE cơ bản.

Các lệnh cấu hình quan trọng cho một giao tiếp đường hầm MPLS cơ sở:

Lệnh Mô tả interface Tunnel0 Các đường hầm MPLS TE được đặc trưng là một giao tiếp đường hầm trong phần mềm Cisco IOS. Nó không khác gì

đối với các loại đường hầm khác. ip unnumbered loopback0

Phần mềm Cisco IOS không chuyển tiếp lưu lượng xuống một giao tiếp không có địa chỉ IP nên phải gán địa chỉ IP cho đường hầm TE vừa tạo. Tuy nhiên các đường hầm TE chỉ theo một hướng duy nhất và không tiếp nhận bất cứ liên kết láng giềng nào nên sẽ lãng phí địa chỉ nếu gắn địa chỉ IP cho giao tiếp đó.

tunel mode mpls Lệnh này thông báo cho phần mềm Cisco IOS biết giao tiếp



traffic-eng đường hầm này là một đường hầm MPLS TE tunnel destination destination-ip

Cho Cisco IOS biết điểm kết thúc của đường hầm. Địa chỉ IP ở đây là MPLS TE RouerID của bộ định tuyến mà bạn muốn tạo đường hầm tới. Địa chỉ IP đích là giao diện Loopback0.

tunnel mpls traffic-eng paht-option 10 dynamic

Cho Cisco IOS biết cách phát sinh đường đi từ đầu đến cuối đường hầm.

Các dạng thông tin chính được phân phối

Một là, thông tin về băng thông có sẵn trên giao tiếp, cho phép một số đường hầm làm việc trước những đường hầm khác nhờ vào độ ưu tiên. Hai là, các cờ thuộc tính trên giao tiếp. Ba là, trọng lượng quản trị trên giao tiếp. Mỗi thông tin này được quảng bá (advertised) trên một cơ sở liên kết (per-link basis). Nói cách khác, một router quảng bá băng thông có sẵn, các cờ thuộc tính và trọng lượng quản trị trên tất cả các liên kết có liên quan trong MPLS TE.

Băng thông có sẵn (available bandwidth)

Một thuộc tính quan trọng của MPLS TE là khả năng dành riêng băng thông qua mạng. Cấu hình một lượng băng thông dành riêng trên một liên kết bằng cách sử dụng lệnh sau:

router(config-if)#ip rsvp bandwidth [<1-10000000 total-reservable-bandwidth>[per-flow-bandwidth]]

Lệnh này có thể lấy hai tham số. Tham số đầu là tổng lượng băng thông dành riêng trên giao tiếp, tính bằng Kbps. Tham số thứ hai là lượng băng thông tối đa có thể dành riêng trong luồng lưu lượng trên một giao tiếp. Nếu không cấu hình lệnh thì băng thông dành riêng ngầm định quảng cáo cho giao tiếp bằng 0. Nếu không chỉ định giá trị cho total-reservable-bandwidth trong lệnh ip rsvp bandwidth thì giá trị mặc định là 75% của băng thông liên kết (link bandwidth). Băng thông liên kết được xác định bởi loại giao tiếp hoặc lệnh về băng thông trên giao tiếp. Tỉ lệ trên luồng lưu lượng (per-flow) tối đa được ngầm định là bằng tham số total-reservable-bandwidth, nhưng không nhất thiết phải luôn luôn như thế. Khi các đường hầm MPLS TE dành riêng băng thông liên kết, lượng băng thông được định phần (allocated bandwidth) thay đổi nhưng băng thông có sẵn tối đa (maximum available bandwidth) không thay đổi. Cần cấu hình cho cả hai: trên giao tiếp (per-interface) và băng thông đường hầm (tunnel bandwidth). Vì hai mục đích. Một là, cấu hình per-interface cho biết trong mạng có bao nhiêu băng thông có sẵn trên một giao tiếp. Hai là, cấu hình per-tunnel ở đầu đường hầm cho biết nó cần bao nhiêu băng thông để sử dụng.

Độ ưu tiên đường hầm (Tunnel Priortity)

MPLS TE cung cấp cơ chế ưu tiên cho một số đường hầm làm việc trước những đường hầm khác. Mỗi đường hầm có một độ ưu tiên, các đường hầm ít quan trọng hơn bị đẩy ra khỏi đường đi và được tính toán lại đường đi, và tài nguyên của nó nhường lại cho đường hầm quan trọng hơn.

Các mức độ ưu tiên (Priority Level):

Một đường hầm có thể được thiết lập độ ưu tiên với giá trị trong khoảng từ 0 đến 7. Giá trị ưu tiên càng lớn thì sự quan trọng của đường hầm càng thấp! Ví dụ, đường



hầm có độ ưu tiên 3 thì quan trọng hơn đường hầm ưu tiên 5. Độ ưu tiên 0 là quan trọng nhất. Để tránh nhầm lẫn người ta thường dùng thuật ngữ “tốt hơn” (better) và “tệ hơn” (worse) hơn thuật ngữ “cao hơn” (higher) và “thấp hơn” (lower). Cũng có thể dùng thuật ngữ “quan trọng hơn” (more important) và “ít quan trọng hơn” (less important).

Những cơ sở của sự chiếm quyền(Preemption Basics):

Những đường hầm quan trọng hơn có quyền đẩy những đường hầm khác ra khỏi đường đi khi muốn dành riêng băng thông. Điều này được gọi là sự chiếm trước đường hầm (tunnel preemption).

Độ ưu tiên thiết lập và độ ưu tiên lưu giữ (Setup and Holding Priority):

Mỗi đường hầm có hai độ ưu tiên – Độ ưu tiên thiết lập (Setup priority) và độ ưu tiên lưu giữ (Hold priority). Cả hai độ ưu tiên được xác định chi tiết trong RFC 3209. Khi một đường hầm được thiết lập lần đầu tiên ta quan tâm đến độ ưu tiên thiết lập của nó lúc quyết định công nhận đường hầm đó. Khi có đường hầm khác đến cạnh tranh băng thông trên liên kết với đường hầm đầu tiên này, độ ưu tiên thiết lập của đường hầm mới được so sánh với độ ưu tiên lưu giữ của đường hầm đầu tiên. Độ ưu tiên thiết lập có thể khác với độ ưu tiên lưu giữ cho một vài ứng dụng thực tế. Ví dụ, một đường hầm có độ ưu tiên lưu giữ bằng 0, và độ ưu tiên thiết lập là 7. Đường hầm này có thể bị bất kỳ một đường hầm khác đẩy ra khỏi đường đi của nó để chiếm tài nguyên vì đường hầm có độ ưu tiên thiết lập thấp nhất (7). Nhưng ngay lúc nó được thiết lập thì không đường hầm nào khác có thể chiếm trước đường đi của nó do có độ ưu tiên lưu giữ cao nhất (0).

Chú ý: cùng một đường hầm thì độ ưu tiên thiết lập không được tốt hơn độ ưu tiên lưu giữ. Vì nếu hai đường hầm (giả sử là Tunnel1 và Tunnel2) đang tranh chấp cùng tài nguyên, và cả hai đều có độ ưu tiên thiết lập bằng 1 và độ ưu tiên lưu giữ bằng 7, điều gì xảy ra? Tunnel1 đến đầu tiên và giữ băng thông với độ ưu tiên lưu giữ bằng 7. Tunnel2 đến thứ hai và dùng độ ưu tiên thiết lập của nó (1) đẩy Tunnel1 ra để chiếm đường liên kết (link). Sau đó Tunnel2 giữ đường liên kết với độ ưu tiên lưu giữ bằng 7. Tunnel1 đến và sử dụng độ ưu tiên thiết lập (1) đẩy Tunnel2 đi và chiếm đường liên kết. Tunnel2 giữ liên kết với độ ưu tiên lưu giữ bằng 7. Tunnel2 đến và dùng độ ưu tiên thiết lập của nó (1) đẩy Tunnel1 ra để chiếm đường liên kết . Sau đó Tunnel2 giữ đường liên kết với độ ưu tiên lưu giữ bằng 7. Cứ thế và lặp lại. Các phiên bản Cisco IOS đều không cho phép cấu hình độ ưu tiên thiết lập thấp hơn độ ưu tiên lưu giữ trên cùng một đường hầm nên trong thực tế không xảy ra hiện tượng trên. Tuy nhiên, trong thực tế hiếm khi độ ưu tiên thiết lập và độ ưu tiên lưu giữ khác nhau.

Cấu hình độ ưu tiên cho đường hầm

Việc cấu hình thì đơn giản. Cấu trúc lệnh :

tunnel mpls traffic-eng priority setup [holding]

Nếu không chỉ định một độ ưu tiên lưu giữ thì ngầm định bằng với giá trị của độ ưu tiên thiết lập. Độ ưu tiên ngầm định là 7 (cho cả hai độ ưu tiên thiết lập và lưu giữ)

Các cờ thuộc tính (Attribute Flags)

Một đặc tính khác của MPLS TE là các cờ thuộc tính. Một cờ thuộc tính là một ảnh bipmap 32-bit trên một kết nối có thể chứa 32 thuộc tính riêng biệt trên một kết nối. Lệnh trên kết nối như sau:



router(config-if)#mpls traffic-eng attribute-flags attributes (0x0-0xFFFFFFFF)

Các thuộc tính (attributes) có thể từ 0x0 đến 0xFFFFFFFF. Nó đại diện một ảnh bitmap của 32 thuộc tính (bit), với giá trị của một thuộc tính là 0 hoặc 1. Ngầm định là 0x0, hay tất cả 32 thuộc tính trong ảnh bitmap là 0. Bạn có thể tự quyết định cho những bit này. Ví dụ, quyết định giá trị cờ thuộc tính là 0x2 nghĩa là “Kết nối này được định tuyến qua một đường vệ tinh và do đó không phù hợp để đi qua những đường có độ trễ thấp (low-delay).” Trong trường hợp này bất kỳ kết nối nào qua vệ tinh sẽ được cấu hình như sau:

router(config-if)#mpls traffic-eng attribute-flags 0x2

Trọng lượng quản tr ị (Administrative Weight)

Chi phí trên kết nối chia làm hai loại: chi phí điều khiển lưu lượng (TE cost) và chi phí của giao thức cổng nội (IGP cost). Cho phép tính toán đường đi TE thiết lập chi phí kết nối khác với đường đi ngắn nhất đầu tiên của giao thức IGP (IGP SPF).Chi phí TE ngầm định trên một kết nối bằng với chi phí IGP. Thay đổi chi phí TE khác với chi phí IGP bằng cách sử dụng lệnh sau:

router(config-if)#mpls traffic-eng administrative-weight (0-4294967295)

administrative-weight là lệnh dùng để thiết lập trọng lượng quản trị hay metric trên một giao tiếp. Lệnh này sử dụng cho hai trường hợp:

Trường hợp 1: ghi đè metric được IGP quảng cáo nhưng chỉ trên những thông tin quảng bá của TE.

Trường hợp 2: là metric nhạy cảm (delay-sensitive metric) với độ trễ trên một cơ sở đường hầm (per-tunnel basis)

Trường hợp 1 được cả OSPF và IS-IS quan tâm, khi một kết nối được quảng bá vào IGP nó kèm theo một metric của kết nối đó (link metric). Metric của kết nối trong IS-IS mặc định là 10, và có thể được cấu hình lại bằng lệnh: per-interface commamd isis metric. Metric kết nốt ngầm định của OSPF bằng băng thông trên kết nối chia 108, và có thể được cấu hình bằng lệnh per-interface commamd ip ospf cost. Nếu trọng lượng quản trị điều khiển lưu lượng mpls (mpls traffic-eng administrative-weight) chưa được cấu hình trên một giao tiếp, chi phí được quảng bá trên thông báo điều khiển lưu lượng bằng với chi phí IGP cho kết nối đó. Tuy nhiên có một trường hợp bạn muốn thay đổi giá trị chi phí được quảng bá trên kết nối cho TE. Điều hày hữu dụng trong các mạng có cả hai loại chuyển tiếp lưu lượng : IP và MPLS TE. Việc cấu hình trọng lượng quản trị trên liên kết sẽ tạo nên sự khác biệt về độ trễ nhưng không thay đổi băng thông.

Thông tin được phân phối khi nào?

Trong một mạng không sử dụng kỹ thuật lưu lượng MPLS, IGP làm tràn (flood) thông tin về một kết nối (link) trong ba trường hợp: Một là, khi một kết nối hoạt động hay không (up or down). Hai là, khi một cấu hình của kết nối thay đổi (Ví dụ: thay đổi chi phí kết nối,…). Ba là, khi đến thời gian làm tràn thông tin IGP định kỳ của router. Các loại bộ định thời được kết hợp với các hoạt động này. Sự khác biệt của chúng phụ thuộc vào giao thức IGP được sử dụng. Kỹ thuật lưu lượng MPLS thêm vào lý do khác để làm tràn thông tin: khi băng thông của kết nối thay đổi. Khi các đường hầm được thiết lập (set up) và được điều khiển (turn down) qua các giao tiếp, lượng băng thông có sẵn trên giao tiếp bị thay đổi để dành riêng (reservation) cho một giao tiếp. Khi các đường hầm được thiết lập trên một giao tiếp, chúng yêu cầu băng thông, và



lượng băng thông có sẵn (available bandwith) giảm xuống; khi các đường hầm được điều khiển xuống qua một giao tiếp cụ thể, lượng băng thông có sẵn tăng lên.

Khi nào router quảng bá những thay đổi băng thông này?

Câu trả lời đầu tiên là “Khi nào có thay đổi xảy ra”. Nhưng nó có thể tạo nên sự tràn ngập rất lớn (tremendous amuont of flooding). Trong các mạng MPLS TE lớn có hàng nghìn đường hầm; việc tái làm tràn ngập (reflooding) khi có một đường hầm thay đổi giống như thêm hàng nghìn kết nối vào IGP. Việc tái làm tràn những thay đối TE không tệ như làm tràn một lượng kết nối IGP tương đương khi bạn không chạy SPF một cách đầy đủ ngay khi có thông tin trạng thái liên kết TE mới nhưng có thể vẫn có rất nhiều thông tin đang làm tràn trên mạng.

Có khả năng một lượng rất lớn thông tin làm tràn ngập chiếm hết băng thông trên mạng và các tài nguyên quan trọng trong CPU của router. Mặc khác, bạn muốn chắc rằng thông tin hình trạng mạng (topology information) được các bộ định tuyến quảng cáo nhằm mục đích cập nhật. Nếu tất cả băng thông trên một kết nối cụ thể được dành riêng, và điều này không quảng bá sự tạm ngưng của mạng, lúc đó mạng ra khỏi sự đồng bộ đang có nên có thể làm cho thiết lập không thành công (setup failures) và những bất lợi khác (suboptimalities). Vì thế bạn phải chú ý khi nào làm tràn những thông tin thay đổi. Có ba nguyên tắc của ngưỡng làm tràn (flooding threshold):

(1) Làm tràn ngay những thay đổi quan trọng.

(2) Khi các đường hầm đến và đi, các ngưỡng được kiểm tra để xem nếu có bất kỳ sự thay đổi nào đối với sự dành riêng qua một ngưỡng, và thông tin trạng thái liên kết TE sẽ được làm tràn khi cần thiết. Băng thông thay đổi gây ra bởi sự dành riêng đường hầm như bảng sau:

Thời điểm

Sự thay đổi băng thông (%)

Băng thông còn lại (%)

Băng thông được chấp nhận (%)

Làm tràn ?

Ngưỡng, chiều?

0 0 100 0 N/A ---

1 10 90 10 N ---

2 1 89 11 N ---

3 2 87 13 N ---

4 2 85 15 Y 15%, ngược dòng

5 35 50 50 Y Cả 30% và 45%, ngược dòng

6 -8 58 42 N ---

7 -20 78 22 Y 30%, xuôi dòng

8 72 6 94 Y 30%, 40%, ngược dòng



9 1 5 95 Y 95%, ngược dòng

10 2 3 97 Y 96%, 97%

11 -3 6 94 Y 96%, 95%, xuôi dòng

(3) Làn tràn những thay đổi không quan trọng một cách định kỳ, nhưng thường xuyên hơn khoảng thời gian làm tươi IGP.

Thời gian định kỳ ngầm định là 180 giây (3 phút). Nhưng có thể thay đổi bằng cách cấu hình sử dụng lệnh toàn cục sau:

lsr1(config)#mpls traffic-eng link-management timers periodic-flooding 0-3600 second interval

Những thông tin này được làm tràn nếu băng thông có sẵn thay đổi và nó chưa được làm tràn. Công việc ngầm định là kiểm tra quản trị kết nối TE (TE link manager) mỗi 3 phút, nếu băng thông dành riêng có thay đổi trên bất kỳ kết nối nào thì làm tràn những thông tin mới về kết nối đó. Thông tin kỹ thuật lưu lượng MPLS không cần làm tràn định kỳ (3 phút) nếu không có sự thay đổi. Chỉ khi có những thay đổi trong vòng 3 phút thì được làm tràn. Chỉ làm tràn định kỳ những thông tin chưa được làm tràn (như một thay đổi băng thông không vượt qua ngưỡng làm tràn). Cài đặt mpls traffic-eng link-management timers periodic-flooding bằng 0 làm vô hiệu việc làm tràn định kỳ. Nghĩa là thông tin băng thông được làm tràn chỉ theo nguyên tắc 1 và 3.

Nếu một thay đổi chưa được làm tràn thì xem như gây ra một lỗi, phải làm tràn ngay: RSVP gửi một lỗi khi một thiết lập đường đi không thành công do thiếu băng thông. Nếu một router nhận một yêu cầu dành riêng băng thông nhiều hơn băng thông hiện có trên một kết nối cụ thể, băng thông kết nối có sẵn được thay đổi tại thời điểm làm tràn thông tin gần nhất vì thế rotuer nhận được sự tiếp nhận dành riêng để bộ định tuyến gửi sự dành riêng chứa những thông tin trong cơ sở dữ liệu cấu trúc mạng (topology database) của nó và thực hiện tái làm tràn (reflood).

Tính toán và thiết lập tuyến

Thuật toán CSPF (Constrained Shortest Path First)

Hoạt động của CSPF:

Có hai điểm khác biệt đáng quan tâm giữa SPF bình thường do các giao thức định tuyến thực hiện và CSPF của MPLS TE. Thứ nhất, tiến trình thiết lập tuyến không được thiết kế để tìm ra đường đi tốt nhất đến mọi bộ định tuyến mà chỉ đến điểm cuối đường hầm (tunnel endpoint). Thứ hai, thay vì chỉ quan tâm đến một loại chi phí trên kết nối giữa hai láng giềng còn phải quan tâm đến:

- Băng thông (bandwidth). - Các thuộc tính kết nối (link attributes) - Trọng số quản trị (Administrative weight) - Bốn thuộc tính được thể hiện trong danh sách PATH/TENT: {link, cost, next

hop, available bandwidth}

Các bước thực hiện thuật toán CSPF như sau:

Bước 1: Một nút tự đưa thông tin của chính mình vào danh sách PATH với cost = 0, next hop là chính nó và thiết lập băng thông = N/A.



Bước 2: Xem xét nút vừa vào danh sách PATH, và gọi nó là nút PATH. Kiểm tra danh sách các nút láng giềng của nó. Thêm mỗi láng giềng vào danh sách TENT với một next hop của nút PATH, trừ khi nút láng giềng đã có có danh sách TENT hoặc PATH với chi phí thấp hơn. Không thêm đường đi này vào TENT trừ khi nó được cấu hình ràng buộc cho đường hầm – băng thông (bandwidth) và quan hệ (affinity). Nếu nút vừa được thêm vào danh sách TENT đã có trong danh sách, nhưng với một chi phí cao hơn hoặc thấp hơn băng thông tối thiểu, thay thế đường đi có chi phí cao hơn bằng đường hiện tại. Bước 3: Tìm láng giềng trong danh sách TENT với chi phí thấp hơn, thêm láng giềng đó vào danh sách PATH, và lặp lại bước 2. Nếu TENT rỗng hoặc trên PATH còn lại nút ở cuối đường hầm thì dừng.

Ví dụ: Minh họa thuật toán CSPF

Quan sát hình trên ta thấy, Router A muốn tạo một đường hầm TE đến router D với băng thông 60 Mbps. Mỗi kết nối liệt kê metric và băng thông sẵn có của nó. Dễ thấy, đường đi tốt nhất từ router A đến Router D là A->B->C->D, với tổng chi phí bằng 12. Nhưng không thỏa băng thông có sẵn bằng 60 Mbps. CSPF cần tính lại đường đi ngắn nhất với băng thông có sẵn 60 Mbps.

Bước 1: Đặt “chính nó” vào PATH với giá trị đường đi = 0, nexthop = self, bandwidth = N/A.

PATH TENT

{A,0,self,N/A} (empty)

Bước 2: Đặt các láng giềng của router A vào TENT.

PATH TENT

{A,0,self,N/A} {B,5,B,100}

{C,10,C,100}

Bước 3: Chuyển B từ PATH sang TENT, và đặt láng giềng của B vào TENT.

PATH TENT



{A,0,self,N/A} {C,10,C,100}

{B,5,B,100} {D,13,B,90}

Bước 4: Đặt láng giềng của B vào TENT, và chuyển C từ TENT sang PATH.

PATH TENT

{A,0,self,N/A} {D,13,B,90}

{B,5,B,100}

Bước 5: Lấy D khỏi TENT. Lúc này, đườc đi tốt nhất đến D nằm trong PATH. Trường hợp này TENT rỗng; D trở thành nút cuối cùng được xem xét trong SPF. Nếu tìm được đường đi tốt nhất đến D mà vẫn còn nút trong TENT, thì vẫn dừng thuật toán ở đây.

PATH TENT

{A,0,self,N/A}

{B,5,B,100}

{C,10,C,100}

{D,13,B,90}

Trong thực tế việc tính toán phức tạp hơn nhiều. CSPF phải lưu giữ mọi nút trên đường đi, không chỉ là nút kế tiếp. Cũng như, không chỉ quan tâm đến băng thông mà còn xem xét đến các thuộc tính kết nối và các phương pháp quyết định (tiebreakers).

Các phương pháp quyết định trong CSPF (Tiebreakers in CSPF)

SPF thông thường (dùng trong OSPF, IS-IS) có thể sử dụng nhiều đường đi đến đích có cùng chi phí. Điều này thỉnh thoảng được gọi là ECMP – Equal-Cost MultiPath, và nó rất hữu dụng trong giao thức định tuyến nội (IGP – Interior Gateway Protocol). Tuy nhiên trong CSPF, không được tính mọi đường đi tốt nhất đến mọi đích có thể. Bạn phải tìm một đường đi đến một đích. Bạn sẽ làm gì khi đặt một nút vào TENT và nút đó đã có trong TENT với cùng chi phí? Bạn cần tìm ra một cách để phân biệt các đường đi với nhau. Đây là các phương pháp quyết định đường đi có cùng chi phí:

- Chọn đường đi có băng thông có sẵn tối thiểu rộng nhất. - Nếu chưa được, chọn đường đi có hop count thấp nhất (số lượng router trong

đường đi).

- Nếu vẫn chưa thõa, chọn đường đi ngẫu nhiên.

Ghi chú:

Mọi thứ không thực sự là “ngẫu nhiên”. Khi xem xét xa hơn trong quá trình quyết định, bạn chọn đường đi trên cùng (top path) trong PATH. Không “ngẫu nhiên” khi mọi đường đi có thể có một cơ hội được lựa chọn, nhưng chọn ngẫu nhiên với đường đi cuối cùng (ends up on the top) của PATH có cấu trúc độc lập và được thực thi độc lập. Các phương pháp này đưa ra cho một nút trong TENT. Tại một thời điểm nào đó,



một nút chỉ nên được liệt kê một lần trong TENT. Đây là sự khác biệt với IGP SPF – có thể chọn nhiều đường cho một nút và chia tải giữa chúng. Giả sử, trong mạng hình bên dưới bạn muốn tạo một đường hầm từ RtrA tới RtrZ với băng thông 10 Mbps. Mỗi đường đi trong mạng này phù hợp với mô tả đó. Khi đó bạn chọn đường nào?

Có 5 đường có thể đi từ A đến Z, gọi là P1 đến P5 (từ trên xuống dưới). Bảng 3 liệt kê các thuộc tính đường đi.

Tên đường Các router trên đường đi Chi phí Băng thông tối thiểu

P1 RtrA→RtrL1→RtrR1→RtrZ 21 100


P3 RtrA→RtrL3→RtrM3→RtrR3→RtrZ 19 90



A lựa chọn một trong những đường sau:

P1 không được sử dụng vì có chi phí đường đi cao hơn các đường khác. P2 không được chọn vì có băng thông tối thiểu là 80 Mbps, thấp hơn băng thông tối thiểu của những đường khác. P3 không chọn vì có hop count = 5, các đường khác có hop count = 4. RtrA chọn P4 hay P5 ở phía trên của TENT.

Những yếu tố khác ảnh hưởng đến CSPF

Phần chia sẻ thông tin cho biết cách sử dụng và cấu hình của băng thông (bandwidth), các thuộc tính kết nối (link attributes), và trọng lượng quản trị (administrative weight) trong hoàn cảnh làm tràn thông tin (information flooding). Nó cũng cho biết cách cấu hình một đường hầm MPLS TE sử dụng các thuộc tính này. Băng thông khá quan trọng. Một đường đi không được chọn sử dụng cho một đường hầm MPLS TE cụ thể



nếu nó không có đủ băng thông yêu cầu. Nếu các affinity bits của một đường hầm không phù hợp với chuỗi thuộc tính được cấu hình trên một kết nối, kết nối đó không được lựa chọn để sử dụng cho một đường hầm MPLS TE cụ thể. Trọng lượng quản trị được sử dụng bởi IGP khi nó làm ngập lụt thông tin điều khiển lưu lượng (traffic enfineering information). Ngầm định chỉ trọng lượng quản trị được dùng để tính toán đường đi của đường hầm. Tuy nhiên, nếu chỉ thay đổi trọng lượng quản trị cho một kết nối cụ thể thì khó có thể tạo nên sự mềm dẻo cần thiết. IGP metric thường được xuất phát từ băng thông. Trong OSPF, metric ngầm định của kết nối là băng thông tham chiếu/ băng thông kết nối (reference-bandwidth/link bandwidth). Băng thông tham chiếu ngầm định (có thể được thay đổi bằng lệnh auto-cost reference-bandwidth) là 108, nghĩa là bất kỳ một kết nối nào 100 Mbps hoặc hơn có chi phí là 1. Ta cũng có thể thiết lập trên một kết nối riêng (individual link) với lệnh ip ospf cost cost. Trong IS-IS, chi phí kết nối ngầm định là 10. Có thể thay đổi chi phí này bằng lệnh isis metric. OSPF và IS-IS thường dùng metric để mã hóa vài số đo của băng thông kết nối. Điều này chỉ tốt cho các mạng chỉ truyền dữ liệu. Cơ chế kiểm soát nghẽn mạng của TCP, khi liên kết với hàng đợi DiffServ, có thể giúp cải tiến băng thông.

Nhưng với thoại thì sao? Thoại (voice) đòi hỏi ít hơn về băng thông và độ trễ lớn hơn. Nhưng không có cách thông báo độ trễ trên một kết nối? Hay nó ở đâu? Có thể vận dụng metric của kết nối IGP để đại diện cho độ trễ hơn là băng thông. Nhưng điều này có thể làm giảm khả năng định tuyến luồng dữ liệu một cách chính xác làm ảnh hưởng nghiêm trọng tới mạng.

Xem xét cấu trúc mạng trong hình sau:

Ba đường đi giữa RtrA và RtrZ là: P1 là một đường vệ tinh OC3 với 150 Mbps băng thông có sẵn và độ trễ cao. P2 là đường viễn thông OC3 với độ trễ thấp. Tuy nhiên, đường viễn thông OC3 không có băng thông có sẵn – tất cả băng thông được dành riêng. P3 là một đường viễn thông DS3 với 45 Mbps băng thông có sẵn và độ trễ thấp.

Vì độ trễ thấp (low-delay), đường đi băng thông lớn (high-bandwidth path) đầy, ta có thể lừa các độ ưu tiên và điều khiển lưu lượng để đường viễn thông OC3 không bị đầy, nhưng không được đề cập trong ví dụ này. Nó dẫn đến hai câu hỏi đơn giản: ta chọn đường đi băng thông cao, độ trễ cao hay đường đi băng thông ít, độ trễ thấp? Trả



lời: “Tùy trường hợp”. Dữ liệu thì vẫn ổn với những đường đi độ trễ cao, thoại thì yêu cầu băng thông ít hơn.

MPLS TE cho ta khả năng quan tâm đến cả băng thông và độ trễ của kết nối, vì thế ta có thể xem xét riêng biệt chi phí của các đường hầm thoại và dữ liệu. Để thực hiện điều này, phải thực hiện các bước sau:

Bước 1: Cấu hình độ trễ của kết nối bằng lệnh mpls traffic-eng administrative-weight 0-4294967295

Bước 2: thay đổi tiến trình quyết định đường hầm (tunnel-decision) trên các đường hầm dữ liệu để dùng IGP metric hơn là dùng TE metric, vì tính đến chi phí kết nối. Bạn có thể thực hiện điều này bằng lệnh toàn cục mpls traffic-eng path-selection metric igp, hay lệnh trên đường hầm tunnel mpls traffic-eng path-selection metric igp.

Không có đơn vị nào cố hữu được kết hợp với cấu hình của trọng lượng quản trị. Nếu bạn cấu hình mpls traffic-eng administrative-weight 10, giá trị 10 có thể được giải thích theo nhiều cách. 10 có phải là độ trì hoãn chuyển tải tính bằng micro giây? Phần trăm giây? Mili giây? Giây? Tuy nhiên nên tính độ trễ theo mili giây (ms) vì:

TE metric là một lượng 32 bit, nghĩa là có thể tính độ trễ trong khoảng 0 – 4.294.967.295 ms (tương đương 7 tuần, một độ trễ lớn chưa từng thấy). Ứng dụng VoIP tính độ trễ bằng ms nên thật sự không cần xem xét độ trễ kết nối bằng bất cứ một đơn vị nào khác. Thật khó đánh giá cụ thể độ trễ đầu cuối (end-to-end latency) trên một mạch (circuit) cụ thể một cách chi tiết với một đơn vị khác ms.

Có ba cách đánh giá độ trễ. Xét theo tính phức tạp tăng dần như sau:

- Ping từ một router này tới một router khác.

- Chỉ định độ trễ mong muốn dựa trên khoảng cách định tuyến (router-miles).

- Dùng SAA để chỉ định độ trễ. CSPF Knobs

Có 3 mảng lớn về tính toán tuyến cần quan tâm là:

- Cấu hình tùy chọn đường đi ở đầu đường hầm

- Bộ định thời CSPF biến thiên (Various CSPF timers)

- Các lệnh hiển thị CSPF thay đổi (Various CSPF show commands)

Cấu hình tùy chọn đường đi (path-option)

Ví dụ : lặp lại cấu hình đường hầm cơ bản interface Tunnel0

ip unnumbered Loopback0

tunnel mode mpls traffic-eng

tunnel destination destination-ip

tunnel mpls traffic-eng path-option 10 dynamic

path-option chỉ định một hoặc nhiều đường đi có thể tạo đường hầm. Hoàn tất cú pháp lệnh như sau :

tunnel mpls traffic-eng path-option preference [dynamic | explicit [identifier

identifier | name name]] {lockdown}

Cú pháp lệnh của tunnel mpls traffic-eng path-option như sau:



Lệnh Mô tả tunnel mpls traffic-eng path-option preference

Xác định một tùy chọn đường đi (path-option) cho đường hầm, tham biến là một giá trị từ 1 đến 1000.

dynamic Cho router biết nó tính toán đường đi tốt nhất phù hợp với cấu hình các ràng buộc của đường hầm, như băng thông và các affinity bits.

explicit Cho phép chỉ định một đường đi tường minh (explicit path) đi qua mạng mà đường hầm được thiết lập. Đường tường minh này phải thõa các ràng buộc cấu hình, và tunnel headend sẽ kiểm tra đường tường minh để chắc rằng các ràng buộc được thõa mãn trước khi truyền tín hiệu trên đường đi.

identifier identifier | name name

Khi các đường tường minh được tạo ra, được định danh hoặc chỉ định. Tùy chọn này chỉ định tùy chọn đường đi nào cần quan tâm.

lockdown Cấu hình lockdown để ngăn một đường hầm TE khỏi bị periodically reoptimized.

Lệnh cấu hình thường dùng là tunnel mpls traffic-eng path-option 10 dynamic.

Tạo một đường đi tường minh (Explicit Path)

Sử dụng tùy chọn nhiều đường đi (Multiple path option)

Tính lại đường hầm (tunnel reoptimization)

Điều gì xảy ra nếu trong lúc một đường hầm đang hoạt động, một đường đi khác tốt hơn xuất hiện.

Trong hình trên:

Tất cả kết nối bắt đầu với băng thông dành riêng là 100 Mbps Cả router A và D đều muốn xây dựng đường hầm 60 Mbps đến router H



Kết nối giữa router D và router H bị đứt.

Ta thấy các sự kiện sau có thể xảy ra:

Router D tạo đường hầm: D → C → H Router A tạo một đường hầm : A → B → C → E → F → G → H Router D giảm băng thông dành riêng trên đường D → C → H xuống 30 Mbps bằng cách cấu hình hoặc điều chỉnh băng thông tự động.

Khi một router tìm thấy một đường đi tốt hơn đường hầm đã được lập thì được xem là reoptimization. Các yếu tố tác động đến reoptimization:

- Tính lại định kỳ (periodic reoptimization).

- Tính lại thủ công (manual reoptimization).

- Tính lại hướng theo sự kiện (Event-driven reoptimization)

Reoptimization không được thực hiện khi đường hầm bị down. Nếu một đường bị down thì không cần đợi bộ định thời reoptimization (reoptimization timer) kích hoạt trước khi tìm ra đường hầm mới mà việc tính toán sẽ được thực hiện ngay lập tức.

RSVP-TE có một cơ chế gọi là make-before-break để thực hiện tạo một đường hầm dành riêng mới mà không làm xáo trộn bất kỳ sự dành riêng đường hầm nào đang tồn tại. Reoptimization định kỳ (periodic reoptimization)

Cisco thực thi một bộ định thời reoptimization định kỳ (periodic reoptimization timer), nó có thể được cấu hình toàn cục. Sau khi một đường hầm đi vào hoạt động, tiến hành một sự cố gắng tìm ra một đường đi mới cho nó, theo các ràng buộc được cấu hình của đường hầm. Ngầm định, việc này được thực hiện 1 lần mỗi giờ; Bộ định thời này được cấu hình bằng lệnh mpls traffic-eng tunnels reoptimize timers frequency 0-604800. 0-604800 là thời gian tính bằng giây mà Cisco IOS Software tìm kiếm một đường đi tốt nhất cho một đường hầm. Thiết lập bộ định thời này bằng 0 nghĩa là đường hầm không bao giờ reoptimize sau khi chúng được thiết lập.

Ghi chú: dù reoptimization timer chỉ được cấu hình toàn cục nhưng được lưu theo từng đường hầm. Giả sử, có 20 đường hầm khác nhau (từ T1 đến T20), mỗi đường hầm được thiết lập cách nhau 2 phút (T1 thiết lập tại 00:00, T2 là 00:02,…T20 lúc 00:40). 20 phút sau đó bộ định thời reoptimization toàn cục (global reoptimization timer) cho T1 kích hoạt và cố tìm một đường đi tốt hơn, nhưng chỉ cho T1. T20 không thực hiện reoptimize đến thời điểm sau khi nó được thiết lập 1 giờ (01:40).

Reoptimization thủ công (manual reoptimization)

Khi có một thay đổi trong mạng mà bạn không muốn đợi reoptimization timer của đường hầm kích hoạt trước khi tìm ra đường đi tốt hơn, bạn có thể sử dụng lệnh mức enable: mpls traffic-eng reoptimize [tunnel-name] để buộc router thực hiện reoptimize một đường hầm cụ thể tại bất kỳ lúc nào.

Reoptimization hướng theo sự kiện (Event-driven reoptimization)

Xem xét kết nối giữa RtrD và RtrH trong hình trên. Nếu kết nối hoạt động, RtrD có nên reoptimize đường hầm D → H của nó để đường hầm này đi qua đường kết nối trực tiếp này? Có thể! Nhưng có một cách mà một kết nối thiết lập nhưng không cần kích hoạt một reoptimization. Cú pháp lệnh:

mpls traffic-eng reoptimize events link-up



Lockdown

Có thể có một vài đường hầm không cần reoptimize. Có thể thực hiện điều này trong phần cơ sở của đường hầm sử dụng tùy chọn lockdown trong các lệnh tùy chọn đường đi:

tunnel mpls traffic-eng path-option preference {dynamic | explicit name name |

identifier id>} {lockdown}

Ví dụ: mỗi kết nối bắt đầu với 100 Mbps băng thông có sẵn

Tại thời điểm hai đường hầm được thiết lập, kết nối bên dưới giữa RtrC và RtrD bị down. Một lúc sau hoạt động trở lại. Một đường hầm 60 Mbps từ RtrA đến RtrE qua kết nối trên C → D và một đường hầm RtrB đến RtrE đi trên cùng kết nối như hình sau:

Khi reoptimize xảy ra trên các đường hầm này, giả sử xem xét trên đường hầm B → E, kết quả là đường hầm B → E được reoptimize.



Nhưng nếu không muốn đường hầm B → E reoptimize thì cấu hình đường hầm đó với tunnel mpls traffic-eng path-option … lockdown, nó sẽ không reoptimize và chuyển sang kết nối khác. Tuy nhiên, nó sẽ đổ về 1 kết nối C → D nếu kết nối C → D phía trên bị đứt.

Giao thức dành riêng tài nguyên (RSVP- Resource Reservation Protocol)

Sau khi một đường đi được tính toán theo CSPF, đường đi đó được báo hiệu qua mạng nhằm:

- Thiết lập một chuỗi các nhãn theo từng chặn (hop-by-hop chain of labels) đại diện cho đường đi.

- Để sử dụng bất kỳ tài nguyên nào có thể dùng được (băng thông) trên đường đi.

Việc báo hiệu hoàn thành bằng RSVP, cùng với RSVP mở rộng cho MPLS TE. RSVP được xác định RFC 2205, có một số mở rộng trong RFC 2210. MPLS TE mở rộng thêm RSVP được xác định trong RFC 3209.

Tổng quan về RSVP

RSVP là một cơ chế báo hiệu dùng để dành riêng tài nguyên trên một mạng. RSVP không phải là một giao thức định tuyến. Việc quyết định tuyến do IGP (gồm cả các mở rộng TE) và CSPF.

Công việc của RSVP là báo hiệu và duy trì tài nguyên dành riêng qua một mạng. Trong MPLS TE, RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-); không có chính sách lưu lượng trên mặt phẳng chuyển tiếp (forwarding-plane). Khi sử dụng cho các mục đích khác (như VoIP hay DLSW+reservations), RSVP có thể được dùng để dành riêng không gian hàng đợi công bằng có trọng số (WFQ – Weighted Fair Queuing) hay xây dựng các ATM SVC.

Ba chức năng cơ bản của RSVP có :

- Thiết lập và duy trì đường đi (Path setup and maintenance).

- Hủy đường đi (Path teardown).

- Báo lỗi (Error signalling).

RSVP là một soft-state protocol. Nghĩa là cần tái báo hiệu trên mạng để làm tươi định kỳ cho nó. Với RSVP, một yêu cầu bị hủy nếu nó được chỉ định xóa khỏi mạng bằng RSVP hay hết thời gian dành riêng (reservation times out).

Chín loại thông điệp RSVP khác nhau được định nghĩa như sau:

Loại thông điệp Mô tả Path Dùng để thiết lập và duy trì sự dành riêng Resv Gửi hồi đáp cho các thông điệp Path để thiết lập và duy trì sự dành

riêng PathTear Tương tự các thông điệp Path, nhưng được dùng để hủy sự dành

riêng ra khỏi mạng. ResvTear Tương tự như các thông điệp Resv, nhưng dùng để hủy sự dành

riêng ra khỏi mạng. PathErr Được gửi bởi phía nhận thông thiệp Path báo rằng phát hiện ra một

lỗi trong thông điệp đó. ResvErr Được gửi bởi phía nhận thông thiệp Resv báo rằng phát hiện ra một

lỗi trong thông điệp đó.



ResvConf Tùy chọn gửi lại cho phía gửi thông điệp Resv để báo rằng tài nguyên dành riêng đưa ra đã được thiết lập.

ResvTearConf Một thông điệp riêng của Cisco tương tự như ResvConf. Báo rằng sự dành riêng đã bị hủy khỏi mạng.

Hello Một sự mở rộng được xác định trong RFC 3209 cho phép kết nối cục bộ (link-local) được duy trì giữa hai láng giềng RSVP kết nối trực tiếp.

Thiết lập đường đi (Path Setup)

Sau khi đầu đường hầm (tunnel headend) hoàn thành CSPF cho một đường hầm cụ thể, nó gửi một thông điệp Path đến nút kế tiếp (next-hop) dọc theo đường đi đã tính toán đến đích. LSR gửi thông điệp Path được gọi là LSR ngược dòng (upstream router), và LSR nhận thông điệp được gọi là LSR xuôi dòng (down-stream router) hay trạm trước đó ( phop – previous hop).

Sau khi LSR xuôi dòng nhận một thông điệp Path, nó kiểm tra định dạng của thông điệp, sau đó kiểm tra lượng băng thông mà thông điệp yêu cầu. Tiến trình này được gọi là điều khiển nhấp nhận (admission control).

Nếu việc kiểm tra này thành công và thông điệp Path được phép dành riêng băng thông như nó yêu cầu, LSR xuôi dòng tạo một thông điệp Path mới và gửi đến nút kế trong đối tượng tuyến tường minh (ERO – Explicit Route Object). Thông điệp Path tiếp tục được chuyền đi đến khi nào chúng đến được nút cuối cùng trong ERO – đuôi đường hầm MPLS TE (tunnel tail).

Đuôi đường hầm thực hiện điều khiển chấp nhận trên thông điệp Path giống như các LSR xuôi dòng khác. Khi nó nhận ra rằng nó là đích đến của thông điệp Path nó trả lời lại bằng thông điệp Resv. Resv đóng vai trò như là một ACK báo về cho LSR ngược dòng. Resv chứa một thông báo rằng thõa mãn sự dành riêng đến cuối đường hầm và thông tin nhãn đến (incoming label) cho LSR ngược dòng sử dụng để gửi các gói dọc theo TE LSP đến đích. Sự trao đổi các thông điệp RSVP Path và Resv trong suốt quá trình thiết lập LSP như sau:

Giả sử rằng R1 thực hiện CSPF xong và biết rằng nó muốn dành riêng băng thông dọc theo đường R1 → R2 → R3 → R5 → R6 → R7:

(1) R1 gửi một thông điệp Path đến R2. R2 nhận thông điệp Path , kiểm tra cú pháp thông điệp và kiểm ra bằng bộ quản lý kết nối TE (TE Link Manager) để chắc rằng băng thông mà R1 yêu cầu hiện đang có sẵn. Nếu xảy ra lỗi R2 gửi thông điệp Error lại cho R1. Giả sử mọi thứ đều tốt thì chuyển sang bước 2.



(2) R2 gửi thông điệp Path đến R3. R3 thực hiện kiểm tra giống R2.




(6) R7, đuôi của đường hầm, gửi một thông điệp Resv đến R6. Resv chỉ định nhãn R7 muốn thấy trên gói đến; vì R7 là đuôi nên nó gửi implicit-null.

(7) R6 gửi một thông điệp Resv cho R5 và chỉ định nó muốn thấy nhãn đến là 42 cho đường hầm này. Nghĩa là khi R6 nhận nhãn 42, nó thực hiện hủy nhãn (vì implicit-null) và gửi thông điệp về cho R7.

(8) R5 gửi thông điệp Resv cho R3, báo hiệu nhãn 10921. Khi R5 nhận một gói với nhãn 10921, nó đổi (swap) nhãn đó thành nhãn 42 và gửi gói đến R6.

(9) R3 gửi một thông điệp Resv cho R2, báo hiệu nhãn 21.

(10) R2 gửi một thông điệp Resv cho R1, báo hiệu nhãn 18.

Lúc này, R1 nhận một thông điệp Resv cho đường hầm đến R7 và nó biết nhãn ra (outgoing label) nào được sử dụng. Giao tiếp đường hầm trên R1 trở thành up/up (trước thời điểm này là up/down).

Duy trì đường đi (Path Maintenance)

Thoạt nhìn, việc duy trì đường đi giống như thiết lập đường đi. Mỗi 30 giây đầu đường hầm gửi một thông điệp Path đến láng giềng xuôi dòng của nó. Nếu một LSR gửi đi một dãy 4 thông điệp Path và không thấy Resv, nó nghĩ rằng sự dành riêng bị mất và gửi một thông điệp ngược dòng (message upstream) báo rằng sự dành riêng bị mất. Các thông điệp Path và Resv được gửi độc lập và bất đồng bộ giữa các láng giềng với nhau. Mỗi 30 giây, R1 gửi thông điệp Path cho một sự dành riêng của nó tới R2. Và mỗi 30 s, R2 gửi một thông điệp Resv đến R1 với cùng sự dành riêng đó. Tuy nhiên hai thông điệp này không liên hệ nhau. Thông điệp Resv được dùng để làm tươi (refresh) một sự dành riêng dang tồn tại chứ không phải trả lời cho thông điệp Path.

Hủy đường đi (Path Teardown)

Nếu một nút (thường là đầu đường hầm) quyết định một sự dành riêng không còn cần thiết trong mạng, nó gửi một thông điệp PathTear dọc theo đường thông điệp Path đã đi và một ResvTear dọc theo đường của Resv.

Thông điệp ResvTear được gửi để hồi đáp cho PathTear báo hiệu đuôi đường hầm. PathTear và ResvTear cũng được gửi để trả lời một điều kiện lỗi trong mạng.

Không giống thông điệp làm tươi, PathTear không cần đi đến hết downstream trước khi nhận được kết quả. Trong hình trên, nếu R1 gửi PathTear đến R2, ngay lập tức R2 trả lời bằng một ResvTear, sau đó gửi PathTear xuôi dòng của nó.

Báo lỗi Thỉnh thoảng, tín hiệu RSVP có thể bị lỗi. Các lỗi này được báo hiệu bằng thông điệp PathErr hay ResvErr. Thông điệp lỗi được gửi ngược dòng về phía nguồn của lỗi; một PathErr được gửi ngược dòng từ một nút xuôi dòng và một ResvErr được gửi xuôi dòng từ một nút ngược dòng.

Các gói RSVP



Định dạng gói RSVP khá đơn giản. Mỗi thông điệp RSVP gồm có một tiêu đề chung (common header), theo sau là một hoặc nhiều đối tượng. Số lượng đối tượng phụ thuộc vào thông điệp đang cố hoàn thành.

RSVP common header

Các trường trong tiêu đề chung RSVP: Trường Mô tả Version Phiên bản của giao thức RSVP. Flags Chưa có cờ nào được định nghĩa. Message Type 1 = Path message

2 = Resv message 3 = PathErr message 4 = ResvErr message 5 = PathTear message 6 = ResvTear message 7 = ResvConf message 10 = ResvTearConf message 20 = Hello message

RSVP Checksum Kiểm tra lỗi của thông điệp RSVP. Send TTL Giá trị TTL trên gói IP. Reserved Không sử dụng. RSVP Length Chiều dài của thông điệp RSVP tính bằng byte bao gồm cả tiêu

đề chung, tối thiểu là 8 byte.

Định dạng lớp đối tượng RSVP

Các đối tượng RSVP có cùng định dạng cơ bản như sau:

Các trường trong định dạng đối tượng RSVP cơ bản:

Trường Mô tả Object Length Kích thước của đối tượng RSVP, gồm cả tiêu đề đối tượng

(object header), tối thiểu là 4. Nó phải là bội số của 4. Class-Num Lớp của đối tượng (object's class). C-Type Loại lớp của đối tượng. C-Type là một số duy nhất trong lớp.



Object Contents Bản thân đối tượng đó.

Mỗi lớp có không gian chỉ số C-Type của riêng nó. Các chỉ số C-Type là duy nhất trong một lớp.

Ví dụ: lớp SESSION có 4 loại C-Types: IPv4, IPv6, LSP_TUNNEL_IPv4, và LSP_TUNNEL_IPv6. Các chỉ số được gán cho C-Types này là 1, 2, 7, and 8. LABEL_REQUEST có 3 C-Types: Without Label Range, With ATM Label Range, và With Frame Relay Label Range. Các số được gán là 1, 2, và 3. Nếu chỉ có C-Type = 1 thì không đủ để xác định duy nhất nội dung một thông điệp; Bạn cần phải xem xét cả lớp và chỉ số C-Type.

Một thông điệp RSVP chứa một hoặc nhiều đối tượng. Số đối tượng trong thông điệp phụ thuộc vào định nghĩa của thông điệp.

Các lớp và C-Types được dùng trong RSVP-TE của Cisco:

Lớp đối tượng C-Type Giá trị C_type SESSION LSP Tunnel IPv4 4 TIME_VALUES Refresh Period 1 ERROR_SPEC IPv4 Error Spec 1 SCOPE List of IPv4 Source Addresses 1 STYLE Flags and Option Vector 1 FLOWSPEC Intserv Flowspec 2 FILTER_SPEC LSP Tunnel IPv4 7 SENDER_TEMPLATE LSP Tunnel IPv4 7 SENDER_TSPEC Intserv Sender Tspec 2 ADSPEC Intserv Adspec 2 RESV_CONFIRM IPv4 RevConfirm 1 RSVP_LABEL Label 1 LABEL_REQUEST Without Label Range 1 EXPLICIT_ROUTE Explicit Route 1 RECORD_ROUTE Record Route 1 HELLO Request 1 HELLO Acknowledgment 2 SESSION_ATTRIBUTE LSP Tunnel 7

Lớp SESSION

Đối tượng SESSION được xác định trong RFC 2205. RFC 3209 định nghĩa C-Type 7 (LSP_TUNNEL_IPV4), có 4 trường được mô tả trong bảng 4-25.



Các trường trong lớp SESSION:

Trường Nội dung IPv4 Tunnel Endpoint Address

Router ID của đuôi đường hầm.

Reserved = 0 Tunnel ID Một 16-bit ID xác định duy nhất đường hầm này. Đây là chỉ số

giao tiếp ở đầu đường hầm (vì thế Tunnel8 có Tunnel ID bằng 8). Extended Tunnel ID Một 32-bit ID. Thiết lập tất cả bằng 0 hoặc một địa chỉ IP của giao

tiếp.

Lớp TIME_VALUES

RFC 2205 định nghĩa đối tượng TIME_VALUES như là chu kỳ làm tươi (refresh period) (tính bằng mili giây - ms để gửi thông điệp Path hay Resv.

Lớp ERROR_SPEC

RFC 2205 định nghĩa đối tượng ERROR_SPEC và cũng xác định các mã lỗi từ 00 đến 23. RFC 3209 định nghĩa mã lỗi 24, đặc tả lỗi cho MPLS TE. Trong MPLS TE, rất dễ gặp mã lỗi 00 ( Sự xác nhận (Confirmation) — gửi trong phúc đáp cho một thông điệp chứa đối tượng CONFIRMATION) hay mã lỗi 24.

Khi mã lỗi (error code) là 00, giá trị lỗi (error value) cũng là 00.

Khi mã lỗi là 24 thì có thể có 10 giá trị. Cũng có một mã lỗi 25 nhưng chỉ thấy khi sử dụng tái định tuyến nhanh (Fast Reroute).

Thông thường trường Flags bằng 0 khi sử dụng MPLS TE.

Lớp SCOPE



RFC 2205 xác định lớp SCOPE. Lớp SCOPE thực hiện kiểu dành riêng wildcard (wildcard reservation style)

Lớp STYLE

Lớp STYLE đặc tả kiểu dành riêng. Có thể có 3 loại: Wildcard Filter Fixed Filter Shared Explicit

Cisco IOS Software sử dụng Shared Explicit cho sự dành riêng MPLS TE.

Trường Flags không được sử dụng. Option Vector luôn bằng 0x12, chỉ định loại Share Explicit.

Lớp FLOWSPEC



Lớp FLOWSPEC được xác định trong RFC 2210. Cisco IOS Software yêu cầu dịch vụ tải được điều khiển (Controlled-Load) khi dành riêng cho một đường hầm TE. Định dạng FLOWSPEC phức tạp và có nhiều thứ trong đó mà RSVP cho MPLS TE không sử dụng.

FLOWSPEC được dùng trong các thông điệp Resv - Resv, ResvTear, ResvErr, ResvConf, ResvTearConf. MPLS TE sử dụng phần tốc độ trong bình của FLOWSPEC để chỉ định băng thông mong muốn, tính bằng byte (không phải bit). Vì thế nếu bạn cấu hình với tunnel mpls traffic-eng 100000 để yêu cầu 100 Mbps băng thông, nó phát tín hiệu 12,500,000 bytes trong một giây (100 Mb = 100,000 Kb = 100,000,000 bits = 12,500,000 bytes).

Lớp FILTER_SPEC

Lớp FILTER_SPEC được xác định trong RFC 2205. RFC 3209 thêm vào C-Type 7, LSP Tunnel IPv4. Trường IPv4 Tunnel Sender Address cho biết router ID của đầu đường hầm TE (TE tunnel headend), và trường LSP ID cho biết tunnel's LSP ID. LSP ID khi các đặc tính của đường hầm (tunnel's properties) thay đổi (băng thông, đường



đi thay đổi). FILTER_SPEC chỉ dùng trong các thông điệp liên quan Resv (ResvTear, ResvErr, ...).

Lớp SENDER_TEMPLATE

Lớp SENDER_TEMPLATE được xác định trong RFC 2205, và RFC 3209 xác định C-Type 7, LSP Tunnel IPv4. Có cùng định dạng và mục đích như lớp FILTER_SPEC nhưng khác hướng.

Lớp SENDER_TSPEC

Thường chỉ thấy lớp SENDER_TSPEC trong thông điệp Path. Giống như FLOWSPEC, MPLS TE chỉ quan tâm tới phần tốc độ trung bình (average rate section).

Lớp ADSPEC



Xác định trong RFC 2210. Giống SENDER_TSPEC, ADSPEC chỉ dùng trong các thông điệp Path.

Lớp RESV_CONFIRM

RESV_CONFIRM được xác định trong RFC 2205. Nó gửi tín hiệu yêu cầu một chấp nhận (confirmation); nó xuất hiện trong các thông điệp Resv và ResvTear. Lớp RESV_CONFIRM thỉnh thoảng xem như CONFIRM.

Lớp RSVP_LABEL

Lớp RSVP_LABEL (thỉnh thoảng được gọi là LABEL) được xác định trong RFC 3209. kích thước 32-bit, mọi đối tượng RSVP phải là bội số của 4 byte, nhưng trong chế độ khung (frame mode), nó mang nhãn 20-bit dùng cho một đường hầm cụ thể (particular tunnel). Lớp RSVP_LABEL chỉ có trong thông điệp Resv.

Lớp LABEL_REQUEST

Đối tượng LABEL_REQUEST yêu cầu một nhãn. Một đối tượng RSVP_LABEL trả lời cho nó. Đối tượng LABEL_REQUEST chỉ có trong thông điệp Path. Nó chứa, trong 16 bit cao, Layer 3 Protocol Identifier (L3PID) được mang trong nhãn. Cisco IOS luôn báo hiệu 0x800 (IP); sự tồn tại của L3PID mang tính lịch sử. Sự tồn tại của



đối tượng LABEL_REQUEST đủ để báo cho nút xuôi dòng (downstream node) là nó tiếp nhận nhãn đưa ra.

Lớp EXPLICIT_ROUTE

Đối tượng EXPLICIT_ROUTE đường đi cho đường hầm MPLS TE, thường được gọi là ERO, và được xác định trong RFC 3209. ERO chỉ có trong thông điệp Path.

ERO là một tập các đối tượng con (8-byte). Đối tượng con IPv4 Prefix hiện tại chỉ được hỗ trợ bởi Cisco IOS.

Các trường trong ERO:

Trường Nội dung L(Loose) Một bit để xác định là một trạm ràng buộc chặt (strict) hay lỏng

(loose) Type Loại đối tượng. IPv4 loại 1. Còn có loại khác như: IPv6, AS Length Chiều dài đối tương (tính bằng byte) IPv4 Address Địa chỉ IP kế tiếp trong ERO Prefix Length

Chiều dài prefix của địa chỉ IP

Reserved Dành riêng (chưa dùng)

Lớp RECORD_ROUTE

Đối tượng RECORD_ROUTE được mô tả trong RFC 3209. Có hai đối tượng con RECORD_ROUTE khác nhau; một để lưu địa chỉ IP ở mỗi trạm (hop) , và một để lưu nhãn (label) được dùng ở mỗi trạm.

Các trường trong đối tượng RECORD_ROUTE:



Trường Nội dung Type 0x1 cho địa chỉ IPv4. 0x3 cho nhãn. Length Chiều dài của đối tượng. IPv4 Address Một địa chỉ IP mà LSP này đi qua. Prefix Length =32. Flags (trong đối tượng con địa chỉ IP)

0x1 chỉ định sẵn sàng bảo vệ cục bộ (Local Protection Available). 0x2 chỉ định bảo vệ cục bộ (Local Protection) đang được dùng.

Flags (trong đối tượng con - nhãn)

0x1 xác định nhãn vừa được ghi là từ không gian nhãn toàn cục.

C-Type C-Type của nhãn. Giống như C-Type cho đối tượng RSVP_LABEL. (Hiện tại giá trị được định nghĩa là 1)

Contents Nhãn của nó, được mã hóa trong đối tượng RSVP_LABEL.

Lớp HELLO

Lớp HELLO có hai C-Types: Hello Request (Type 1) và Hello ACK (Type 2). Cả hai được mã hóa giống nhau. Source Instance và Destination Instance để lưu trạng thái láng giềng RSVP (RSVP neighbor state); xem thông điệp HELLO như là báo hiệu tồn tại mức RSVP (RSVP-level keepalives).

Lớp SESSION_ATTRIBUTE

Lớp SESSION_ATTRIBUTE đuợc định nghĩa trong RFC 3209. SESSION_ATTRIBUTE chỉ có trong thông điệp Path. SESSION_ATTRIBUTE có hai loại—có hoặc không có resource affinity (RA). Hiện tại, Cisco IOS chỉ hỗ trợ LSP Tunnel C-Type không có RA (C-Type 7).

Các trường trong đối tượng SESSION_ATTRIBUTE:

Trường Nội dung Setup Priority Độ ưu tiên thiết lập Holding Priority Độ ưu tiên chiếm giữ Flags 0x2 = bản ghi nhãn (Label recording)

0x1 = Sự bảo vệ cục bộ (Local protection)



0x4 = Kiểu SE. Name Length Chiều dài của chuỗi Session Name, tính bằng byte. Session Name Tên được gán cho LSP này.

Hoạt động của RSVP-TE

Bạn tự hỏi làm thế nào các giao thức có thể phối hợp với nhau. Phần này sẽ trả lời câu hỏi: Make-before-break là gì? Cơ chế làm tươi (refresh mechanism) hoạt động như thế nào? Các thông điệp được gửi khi nào, ở đâu và cho ai? Các đối tượng cin ERO chặt (strict) và lỏng (loose) là gì? Báo hiệu Implicit và explicit null ở trạm cuối là gì?

Make-Before-Break

Make-before-break là một cơ chế RSVP-TE cho phép thay đổi một số đặc tính của đường hầm TE (tên, băng thông và đường đi) mà không làm mất dữ liệu và không cần double-booking bandwidth.

Băng thông được chỉ định trước khi bất kỳ băng thông nào được được dành riêng từ mạng. Nếu R1 truyền tính hiệu yêu cầu 35 Mb đến mạng, nó đi trên đường R1 → R2 → R5. Còn lại băng thông có sẵn trên R1 → R2 10 Mb và trên R2 → R5 65 Mb. Điều gì xảy ra nếu R1 muốn tăng kích thước băng thông dành riêng của nó lên 80 Mb? Băng thông này phải đi từ đường dưới vì không có cách nào lấy được băng thông dành riêng 80 Mb trên đường R1 → R2 → R5. Còn lại băng thông có sẵn 20 Mb trên mỗi kết nối của đường dưới. Trong một khoảng thời gian ngắn, R1 dành riêng băng thông qua cả hai đường và vì thế dành riêng tổng cộng là 115 Mb (35 Mb đường trên và 80 Mb qua đường dưới). Tuy nhiên, sự dành riêng 35 Mb sớm được giải phóng sau khi sự dành riêng 80 Mb được tạo ra. Nguyên tắc của make-before-break làm cho đầu đường hầm (tunnel headend) không giải phóng sự dành riêng cũ đến khi có sự dành riêng mới thay thế giúp giảm tối thiểu việc mất dữ liệu.

Kiểu dành riêng chia sẻ tường minh (Shared Explicit Reservation Style)



Tương tự như trên, R1 cố gắng dành riêng 80 Mb qua R1 → R3 → R4 → R2 → R5. Nhưng không thể! Vì hiện giờ băng thông có sẵn trên R2 → R5 chỉ còn 65 Mb! R1 có thể teardown dành riêng trên đường R1 → R2 → R5 và sau đó xây dựng sự dành riêng trên R1 → R3 → R4 → R2 → R5. Không nên thực hiện như vậy! Có cách tốt hơn để khắc phục hiện tượng này. RSVP có một khả năng gọi là chia xẻ tường minh (SE – Share Explicit). Chia sẻ tường minh SE là một kiểu dành riêng cho phép một LSP đang tồn tại chia sẻ băng thông với chính nó để tránh xảy ra double booking. Hoạt động SE gồm hai phần: Yêu cầu kiểu dành riêng SE từ mạng và xác định sự dành riêng yêu cầu trùng với sự dành riêng dang tồn tại để chia xẻ băng thông. Đầu đường hầm yêu cầu kiểu dành riêng SE sử dụng một cờ (flag) trong đối tượng SESSION_ATTTRIBUTE. Còn một cách giải quyết khác liên quan đến SE được gọi là Bộ lọc tích hợp (FF – Fixed Filter) nhưng không được Cisco MPLS TE thực hiện. Nó không cho phép chia xẻ băng thông như SE nhưng cũng có thể giải quyết được hiện tượng trên.

Mọi sự dành riêng RSVP được xác định duy nhất bằng một bộ năm thông số five-tuple {Sender Address, LSP ID, Endpoint Address, Tunnel ID, Extended Tunnel ID}. Hai mục đầu chứa trong đối tượng SENDER_TEMPLATE (và FILTER_SPEC). Ba mục sau chứa trong đối tượng SESSION. Nếu hai thông điệp Path có 5 mục yêu cầu này trùng nhau thì chúng cùng quan tâm đến một sự dành riêng. Địa chỉ người gửi (Sender Address) là RID của đầu đường hầm. Địa chỉ điểm cuối (Endpoint Address) là RID của đuôi đường hầm. Extended Tunnel ID là 0 hoặc địa chỉ IP trên bộ định tuyến ; nó được dùng trong một số kỹ thuật bảo vệ. Tunnel ID là chỉ số giao tiếp đường hầm tại đầu đường hầm. LSP ID như là ‘bộ đếm (instantiation counter)’: mỗi lần đường hầm thay đổi băng thông yêu cầu của nó hay đường đi, LSP ID tăng lên 1. Nguyên tắc của tiến trình dành riêng ES cho MPLS TE là nếu hai sự dành riêng có các phần trong five-tuple giống nhau, chỉ khác khác LSP ID, nên khác LSP nhưng chúng được chia xẻ băng thông.

Các bước trong Make-Before-Break:

Bước R1 R2 1 Gửi một sự dành riêng cho

{SA=1.1.1.1, LSP ID=1, EA=5.5.5.5, TID=8, XTID=0}, yêu cầu 35 Mb dọc đường đi R1→ R2 → R5 . Gọi là sự dành riêng Res1.

Chuyển tiếp sự dành riêng đến R5. Đánh dấu đường đi R2 → R5 là 35 Mb được dành riêng cho đường hầm cà còn lại 65 Mb .



2 Gửi một yêu cầu dành riêng cho {SA=1.1.1.1, LSP ID=2, EA=5.5.5.5, TID=8, XTID=0} dọc đường đi R1→R3→R4→R2→R5, yêu cầu băng thông 80 Mb. Gọi là Res2.

Kiểm tra sự dành riêng và thấy rằng sự dành riêng này giống với sự dành riêng đã có ngoại trừ LSP ID. Cho phép sự dành riêng mới đụng độ với băng thông dành riêng đã có và định phần cho đường hầm này là 80 – 35 = 45 Mbps nhiều hơn băng thông trên kết nối R2 → R5. R2 → R5 dánh dấu băng thông dành riêng là 80 Mbps và 20 Mbps chưa đuợc sử dụng.

Theo cách này cả Res1 và Res2 được phép cùng tồn tại đến khi Res1 bị xóa khỏi mạng. Sau khi Res2 được chia xẻ băng thông với Res1, thì Res1 sẽ không cố gắng sử dụng băng thông cùng thời điểm với Res2.

Cơ chế làm tươi

RSVP là một giao thức soft-state, sự dành riêng được làm tươi định kỳ. Sự dành riêng được gửi bằng thông điệp Path và Resv. Việc làm tươi để kiểm tra xem sự dành riêng đang tồn tại với five-tuple có phù lợp với yêu cầu trong thông điệp Path hay Resv không.

Hai điểm chính cần nắm khi nói đến cơ chế làm tươi là bộ định thời làm tươi được kích hoạt và thông điệp Path và Resv được gửi độc lập giữa hai bộ định tuyến. Các thông điệp Path và Resv được gửi mỗi 30 giây. Tuy nhiên không thật sự là mỗi 30s; chúng gửi trên một bộ định thời 30s nhưng kích hoạt 50 %. Vì thế sự dành riêng đưa ra có thông điệp Path gửi để làm tươi mỗi 15 đến 45 giây. Tương tự với thông điệp Resv. Việc tính toán làm tươi được xác định trong RFC 2205. Thông thường một láng giềng gửi khoảng thời gian làm tươi R (Refresh interval) tới láng giềng của nó trong đối tượng TIME_VALUES trong thông điệp Path và Resv. Mỗi bộ định tuyến cũng biết được bao nhiêu thông điệp sẽ được bỏ qua trước khi tuyên bố sự dành riêng mất đi (gọi là K). Các láng giềng tính toán thời gian giữ (holdtime) thông điệp này bằng công thức:

L >= (K + 0,5) * 1,5 * R

Hiện tại, R = 30s và K = 3. Suy ra L ít nhất là 157,5 s. Nghĩa là bộ định tuyến có thể đợi 157,5 s trước khi tearing down một láng giềng. Hình dưới cho thấy thông điệp Path và Resv được gửi một cách độc lập và định thời làm tươi của thông điệp Path là 00:00 và 00:45, và của thông điệp Resv là 00:15 và 00:30.



Các thông điệp được gửi khi nào? Đến đâu? Và cho ai?

Các loại thông điệp RSVP:

Thông điệp Chức năng Hướng Địa chỉ đích

Cảnh báo router

Path Gửi tín hiệu yêu cầu tài nguyên lên mạng.

Xuôi dòng Đuôi (tail) Có

Resv Trả lời thông điệp Path thành công.

Ngược dòng Trạm kế (next hop)

Không

PathErr Gửi về đầu đường hầm khi có lỗi ở thông điệp Path.

Ngược dòng Trạm kế Không

ResvErr Gửi về phía đuôi nếu có một lỗi trong việc xử lý thông điệp Path.

Xuôi dòng Trạm kế Không

PathTear Gửi về đuôi đường hầm để hủy một sự dành riêng đang tồn tại.

Xuôi dòng Đuôi Có

ResvTear Gửi về đầu đường hầm để hủy một sự dành riêng dang tồn tại.

Ngược dòng Trạm kế Không

ResvConf Gửi phúc đáp cho Resv hay ResvTear yêu cầu xác nhận thông điệp.

Xuôi dòng Đuôi Có

ResvTearConf Gửi hồi đáp cho một ResvTear bao gồm một thông điệp Confirm.

Xuôi dòng Trạm kế Không

Hello Gửi tới một láng giềng RSVP trên một kết nối trực tiếp.

Ngược dòng / Xuôi dòng

Trạm kế Không



Chú ý:

RFC 2113 giới thiệu một tùy chọn IP được gọi là tùy chọn cảnh báo router (RA – Router Alert). Hiện tại RA được sử dụng trong cả IGMP và RSVP. Nó cho phép bộ định tuyến kiểm tra các gói được truyền và cho bộ định tuyến tùy chọn sửa đổi gói đó trước khi chuyển tiếp đi. Mọi thông điệp có thiết lập tùy chọn RA được gửi theo hướng xuôi dòng. Mọi thông điệp có thiết lập tùy chọn RA có địa chỉ IP đích là đuôi đường hầm. Mọi thông điệp có thiết lập tùy chọn RA hay đặt trạm kế (xuôi dòng hoặc ngược dòng) địa chỉ giao tiếp là địa chỉ đích trên gói.

Thực hiện như thế cho phép bộ định tuyến phát hiện ra các bộ định tuyến không hỗ trợ RSVP (non-RSVP), vì không thể xây dựng một đường hầm TE qua một bộ định tuyến không giao tiếp với RSVP do MPLS TE không chỉ cần băng thông dành riêng mà còn cần sự định vị nhãn.

Các đối tượng con ERO strict và loose

ERO được mã hóa như làm một loạt các đối tượng con được gọi là nút trừu tượng (abstrat nodes). Một nút trừu tượng có thể là địa chỉ IPv4, IPv6, hay một AS (autonomous system). Đối tượng con có thể là một trạm chặt hay lỏng. Cisco thường dùng trạm chặt (strict hop). Khi một bộ định tuyến xử lý một trạm chặt, địa chỉ IPv4 trong đối tượng con phải là kết nối trực tiếp của bộ định tuyến thực hiện xử lý . Khi bộ định tuyến xử lý một trạm lỏng (loose hop), nó phát sinh một tập các trạm chặt để lấy thông điệp Path về đích và thay thế trạm lỏng đó bằng một tập các trạm chặt mới được phát sinh.

Implicit và Explicit Null

Đuôi đường hầm có hai loại tín hiệu nhãn—implicit null và explicit null. Explicit null sử dụng giá trị 0 và Implicit null dùng giá trị 3 trong trường Label của đối tượng LABEL. Ngầm định nút cuối đường hầm gửi tín hiệu implicit null trong thông điệp Resv của nó: LABEL type 1 length 8 : 00000000

Với chất lượng dịch vụ thì cần explicit null.

Cách khoảng thông điệp RSVP (RSVP spacing)

Khi có một sự cố trong mạng (đứt kết nối, khởi động lại router, ...). Điều này tạo ra một lượng rất lớn sự báo hiệu. Nếu đứt kết nối, cần gửi PathErr hay ResvErr cho các đường hầm đi qua kết nối. Nếu có 2000 đường hầm TE qua kết nối thì cần 2000 PathErr/ResvErr. Mỗi thông điệp RSVP đến hàng đợi ngõ vào của một router khác. Hàng đợi này có kích thước ngầm định là 75 gói. Nếu quá nhiều thông điệp và hàng đợi đầy thì có thể làm mất gói. Một điểm không may nữa, khi thông điệp RSVP mất, nút gửi đi sẽ phải đợi đến thời gian làm tươi mới gửi lại thông điệp – 30 s ±- 50%. Giải quyết bằng cách tăng bộ đệm? Tăng bao nhiêu cho đủ? Kết quả truyền loạt có thể làm mất gói và hội tụ chậm. Giải pháp tốt nhất là cách khoảng thông điệp RSVP (RSVP Message Pacing), kiểm soát tốc độ các thông điệp RSVP được gửi để hàng đợi ở đầu cuối kết nối không bị tràn. Thực hiện cấu hình chức năng này bằng lệnh ip rsvp msg-pacing ? với các tùy chọn như sau :

Các tùy chọn của lệnh ip rsvp msg-pacing ?:

Tùy chọn

Chức năng Mặc định

burst Số lượng tối đa các thông điệp RSVP có thể được gửi trong một loạt truyền

200



maxsize Số lượng tối đa các thông điệp được vào hàng đợi để truyền 500 period Khoảng thời gian mà một loạt thông điệp được truyền 1 Chuyển tiếp lưu lượng xuống đường hầm

Phần này ta sẽ khảo sát ba phương pháp chuyển tiếp lưu lượng mpls xuống đường hầm. Một là dùng các tuyến tĩnh (static routes). Hai là dùng định tuyến dựa trên chính sách (policy base routing). Ba là định tuyến tự động (Autoroute).

Sử dụng định tuyến tĩnh (static route)

Cách đơn giản nhất để định tuyến một luồng lưu lượng xuống một giao tiếp đường hầm là sử dụng định tuyến tĩnh (static route). Nó hoạt động giống như định tuyến IP bình thường.

Ví dụ:

ip route 10.0.0.0 255.0.0.0 Tunnel0 ip route 10.0.0.0 255.0.0.0 POS0/0 Sử dụng định tuyến tĩnh đệ quy : ip route 192.168.1.1 255.255.255.255 Tunnel0 ip route 10.0.0.0 255.0.0.0 192.168.1.1

(với: 192.168.1.1 : địa chỉ cuối đường hầm)

Định tuyến dựa trên chính sách (policy base routing)

PBR (Policy Base Routing) được phép sử dụng ánh xạ tuyến theo chính sách áp dụng cho giao tiếp ngõ vào. Với PBR bạn có thể gửi loại lưu lượng cụ thể xuống một giao tiếp đường hầm mà không cần sửa đổi bảng định tuyến của bộ định tuyến.

Ví dụ:

Có hai loại lưu lượng gửi đến Dst – thoại và dữ liệu. Nếu chỉ muốn lưu lượng thoại qua Tunnel0, bạn có thể thực hiện bằng PBR. Thực hiện cấu hình trên bộ định tuyến A như sau :

interface Ethernet0/0 ip policy route-map foo route-map foo match ip address 101 set interface Tunnel0 access-list 101 permit ip any host 5.5.5.5



Định tuyến tự động

Nếu có nhiều loại giao tiếp trong Cisco IOS Software (một giao tiếp vật lí, giao tiếp con, hay đường hầm GRE), bạn cần cho phép giao thức cổng nội (IGP – Interior Gateway Protocol) trên giao tiếp để thiết lập giao thức định tuyến láng giềng, học tuyến, và xây dựng một bảng định tuyến cho giao tiếp đó.

Ví dụ về hoạt động chuyển tiếp lưu lượng xuống đường hầm

Ở đây ta quan tâm đến bảng định tuyến của bộ định tuyến A sau khi sử dụng định tuyến tĩnh, định tuyến dựa trên chính sách và định tuyến tự động trong mạng. Các kết nối đều có chi phí là 10.

Bảng định tuyến ban đầu của A:

Trạm đích Trạm kế Chi phí A Chính nó 0 B B 10 C C 10 D C 20 E B 20 F B 30 G B 30 H B 40 I B 40

Định tuyến tĩnh: Ta cấu hình cho lưu lượng đến G

ip route router G's RID 255.255.255.255 Tunnel0

Bảng định tuyến của A như sau:

Trạm đích Trạm kế Chi phí A Chính nó 0 B B 10 C C 10 D C 20 E B 20 F B 30 G Tunnel0 30 H B 40 I B 40

Định tuyến dựa trên chính sách

Không làm thay đổi bảng định tuyến vì quyết định chuyển tiếp gói dựa trên chính sách được cấu hình và giao tiếp, không dựa trên bảng định tuyến.



Định tuyến tự động

Router xây dựng lại bảng định tuyến để bất kỳ đích đến (đuôi đường hầm nào cũng được định tuyến xuống đường hầm). Router A thực hiện tiến trình IGP SPF với định tuyến tự động được cho phép trên đường hầm đến router E. Bảng định tuyến của A sau quá trình này như sau:

Trạm đích Trạm kế Chi phí A Chính nó 0 B B 10 C C 10 D C 20 E Tunnel0 20 F Tunnel0 30 G Tunnel0 30 H Tunnel0 40 I Tunnel0 40

Date post:	26-Jul-2015
Category:	Documents
Upload:	vu-tien-manh
View:	114 times
Download:	0 times

MPLS

Documents