MPLS - Tieng Viet

VnPro – Cisco Authorized Training Center
CHUYỂN MẠCH NHÃN ĐA

GIAO THỨC
(MPLS MultiProtocol Label Switching)
Tác giả: Trần Thị Tố Uyên
Trần Thị Tố Uyên 1

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.
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
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
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
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
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
ATM, Frame, Replay và IP Internet trên một mặt phẳng đơn trong một đường đi tốc
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ụ
độ 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
MGX8800, Router chuyển mạch đa dịch vụ 8540 và các chuyển mạch Cisco ATM
mạch ATM trong mạng lõi, chuyển mạch nhãn giúp các các dòng Cisco, BPX8600,
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 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
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.
á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
đị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
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ộ
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.
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.
Giảm tải trên mạng lõi
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 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.
Kiểu khung (Frame mode):
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 đó:
để 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=Experimental (3 bit): dành cho thực nghiệm. Cisco IOS sử dụng các bit này
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.

ATM Cell header GFC VPI VCI PT 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
Shim header
Ethernet Ethernet Header Nhãn Header lớp 3 Dữ liệu
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
CLP (Cell Loss Priority): Chức năng chỉ thị ưu tiên huỷ bỏ tế bào
PT (Payload Type): Chỉ thị kiểu trường tin
HEC (Header error check): Kiểm tra lỗi tiêu đề.

Cấu trúc nút của MPLS
đ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
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
lớp hai. Kiến trúc cơ bản của một nút MPLS như sau:
Mặt phẳng điều khiển
Chuyển đổi thông tin

Giao thức định tuyến IP định tuyến
Chuyển đổi thông tin
Giao thức phân phối nhãn liên kết nhãn
Mặt phẳng chuyển tiếp
Các gói IP Bảng định tuyến IP

vừa đến (ECF FIB) Các gói IP ra
Các gói được Cơ sở định tuyến chuyển Các gói IP được

gắn nhãn vừa gắn nhãn ra
đến
tiếp nhãn (LFIB)
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

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)
Mặt phẳng điều khiển một nút mạng
Điều khiển Điều khiển định Điều khiển Điều khiển Chất lượng
định tuyến tuyến MPLS định tuyến Lưu lượng dịch vụ
MPLS IP Multicast IP MPLS/VPN (MPLS TE) (QoS)
Cơ sở thông tin chuyển tiếp

nhãn LFIB
Mặt phẳng dữ liệu tại một nút mạng
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

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
đích trong bảng định tuyến với các trạm kế tiếp (next-hop adjacencies) tương ứng.
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
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
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.
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
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:
Dùng từ khóa [distribute] thể hiện khả năng của chuyển mạch CEF được chia sẻ.
Router(config-if)#ip route-cache cef.
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
láng giềng và các giao tiếp mà tiến trình khám phá LDP đang chạy.
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
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
!
!
memory-size iomem 10
ip subnet-zero
!
!
!
ip cef
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
tag-switching ip
!
router ospf 100
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
…..

O 10.10.10.8/30 [110/128] via 10.10.10.6, 00:23:26, Serial0/1
O 10.10.10.104/32 [110/129] via 10.10.10.6, 00:23:26, Serial0/1
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
0.0.0.0/32 receive
10.10.10.0/32 receive
10.10.10.2/32 receive
10.10.10.3/32 receive
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

ifindex 3(3)
IP MTU 1500



ifindex 4(4)
IP MTU 1500
LSR2#show mpls int

Serial0/0 Yes (ldp) No Yes
LSR2#show mpls ldp dis

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

!
version 12.2
!
hostname LSR3
!

!
ip subnet-zero
!
!
!
ip cef
!
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
network 10.10.10.0 0.0.0.255 area 0
!
end
LSR3#show ip route
….

O 10.10.10.0/30 [110/128] via 10.10.10.5, 00:11:19, 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
O 10.10.10.101/32 [110/129] via 10.10.10.5, 00:11:19, Serial0/1
LSR3# show cdp nei

LSR4 Ser 0/0 131 R 2610 Ser 0/1
LSR2 Ser 0/1 178 R 2610 Ser 0/1
LSR3#show ip cef


0.0.0.0/32 receive
10.10.10.0/30 10.10.10.5 Serial0/1
10.10.10.4/32 receive
10.10.10.6/32 receive
10.10.10.7/32 receive
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

ifindex 3(3)
IP MTU 1500


ifindex 4(4)
IP MTU 1500
LSR3#show mpls interfaces

10.10.10.103:0
Discovery Sources:
Interfaces:
LDP Id: 10.10.10.104:0
LDP Id: 10.10.10.102: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
TCP connection: 10.10.10.104.11004 - 10.10.10.103.646
Up time: 00:12:43
10.10.10.104 10.10.10.10
LSR4#show run

version 12.2
!
hostname LSR4
!
!
ip subnet-zero
!
ip cef
!
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
network 10.10.10.0 0.0.0.255 area 0
!
end
LSR4#show cdp nei

LSR3 Ser 0/1 159 R 2610 Ser 0/0
LSR4#show ip route

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

ifindex 4(4)
IP MTU 1500
LSR4#show mpls int
10.10.10.104:0
Discovery Sources:
Interfaces:
LDP Id: 10.10.10.103:0
TCP connection: 10.10.10.103.646 - 10.10.10.104.11004


Up time: 00:14:34
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
mạng dựa trên bộ định tuyến truyền thống (traditional router-based network), các site
nhau thông qua mạng của nhà cung cấp dịch vụ (SP – service provider). Trong các
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.
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
Khi Frame Relay và ATM cung cấp cho khách hàng các mạng riêng, nhà cung cấp
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
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 peer-to-peer VPN. Tuy nhiên, thay vì triển khai các router PE khác nhau cho từng
phần của một MPLS VPN được trình bày trong hình sau:
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
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.
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
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
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
nhiên, thông tin này cần được mang theo giữa các router PE để cho phép truyền dữ
Trong mô hình MPLS VPN, router PE phân biệt các khách hàng bằng VRF. Tuy
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
liệu giữa các site khách hàng qua MPLS VPN backbone. Router PE phải có khả năng
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
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
VPNs, network management VPN,…) sử dụng công nghệ MPLS VPN thì RT giữ vai
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à
mang một tập các đích đến được (reachable destination) với thông tin trạm kế được
MP_UNREACH_NLRI (Multiprotocol Unreachable NLRI). MP_REACH_NLRI
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
vụ mang và giữ nguyên metric EIGRP khi đi qua MP-iBGP domain. Các community
nhật MP-BGP (MP-BGP update). Các thuộc tính BGP extended community giữ nhiệm
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 Type Usage Value

Attribute
General 0x8800 EIGRP General Route Route Flag and Tag
Information
Metric 0x8801 EIGRP Route Metric AS and Delay
Information and AS
0x8802 EIGRP Route Metric Reliability, Next Hop, and
Information Bandwidth
0x8803 EIGRP Route Metric Reserve, Load, and Maximum
Information Transmission Unit (MTU)
0x8804 EIGRP External Route Remote AS and Remote ID
Information
External 0x8805 EIGRP External Route Remote Protocol and Remote
Information 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
đối với giao thức định tuyến ở CE nên không có EIGRP adjacency hay cập nhật
VPN sử dụng các EIGRP AS khác nhau trên các PE. Vì MPLS backbone là trong suố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
được quảng bá là external route tới CE1-A.

tới CE1-A. Route type của 192.168.99.0 là external nên vì thế cả hai tuyến
(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.
và cùng thuộc EIGRP AS 101. EIGRP AS 101 được cấu hình cho VRF
- Mạng của Customer A – Customer A có CE1-A và CE2-A trong cùng VPN-A
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
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
Thực hiện tương tự cho CustomerA.
(3) Redistribute các tuyến BGP VPNv4 vào EIGRP.
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)# 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
!
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
ip address 10.10.10.6 255.255.255.252
tag-switching ip
!
router ospf 1
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
!
ip cef
!
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
network 172.16.0.0
no auto-summary
exit-address-family
!
router ospf 1
router-id 10.10.10.101
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

!
redistribute eigrp 201
no auto-summary
no synchronization
exit-address-family
!
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
!
ip vrf CustomerB
rd 1:200
!
ip cef
!
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
ip address 10.10.10.5 255.255.255.252
tag-switching ip
clockrate 64000
!
interface Serial1/2
ip address 172.16.2.1 255.255.255.252
!
interface Serial1/4
ip address 192.168.2.1 255.255.255.252
clockrate 64000
!
router eigrp 1
auto-summary
!
network 192.168.2.0
no auto-summary
exit-address-family
!
network 172.16.0.0
no auto-summary
exit-address-family
!
router ospf 1
router-id 10.10.10.102
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no auto-summary
!
no auto-summary

exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
ip http server
ip classless
!
end
Router CE1-A
!
hostname CE1-A
!
ip subnet-zero
!
description VPN-A Site 1 network
ip address 172.16.10.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
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
!


ip address 172.16.20.1 255.255.255.0
no ip directed-broadcast
no keepalive
!
interface Serial0/0
ip address 172.16.2.2 255.255.255.252
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
!
description VPN-B Site 1 network
ip address 192.168.10.1 255.255.255.0
no keepalive
!
interface Serial0/0
ip address 192.168.1.2 255.255.255.252
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
!
ip address 192.168.20.1 255.255.255.0
no keepalive
!
interface Serial0/0
ip address 192.168.2.2 255.255.255.252
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
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
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
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
Paths: (1 available, best #1, table CustomerA)
10.10.10.101
Local
172.16.2.2 from 0.0.0.0 (10.10.10.102)
sourced, best
0x8802:62209:20000000 0x8803:62209:1500
10.10.10.102
Local
172.16.2.2 from 0.0.0.0 (10.10.10.101)
sourced, best
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


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
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à
EIGRP từ CE3-A bị lọc đi vì có cùng giá trị SoO với giao tiếp nhận nó.
một qua MP-iBGP từ PE2-AS1. PE1-AS1 sẽ sử dụng tuyến học từ BGP; tuyế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

!
version 12.2
!
hostname P1-AS1
!
!
ip subnet-zero
!
ip cef
!
interface Loopback0
ip address 10.10.10.200 255.255.255.255
!
interface Serial0/0
ip address 10.10.10.2 255.255.255.252

tag-switching ip
clockrate 64000
!
interface Serial0/1
ip address 10.10.10.6 255.255.255.252
tag-switching ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
!
ip http server
ip classless
!
end
Router PE1-AS1
PE1-AS1#show run

!
version 12.2
!
hostname PE1-AS1
!
ip subnet-zero
!
ip vrf CustomerA
rd 1:100
!
ip cef
!
interface Loopback0
ip address 10.10.10.101 255.255.255.255
!
interface Serial0/0
ip address 10.10.10.1 255.255.255.252
tag-switching ip
no fair-queue
!
interface Serial1/1


ip address 172.16.1.1 255.255.255.252
clockrate 64000
!
interface Serial1/3
ip vrf sitemap SOO-VPNA
ip address 172.16.3.1 255.255.255.252
clockrate 64000
!
router eigrp 1
auto-summary
!
network 172.16.0.0
no auto-summary
exit-address-family
!
router ospf 1
router-id 10.10.10.101
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no auto-summary
!
neighbor 10.10.10.102 send-community both
no auto-summary
exit-address-family
!
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

!
version 12.2
!
hostname PE2-AS1
!
!
ip subnet-zero
!
!
!
ip vrf CustomerA
rd 1:100
!
ip cef
!
!
interface Loopback0
ip address 10.10.10.102 255.255.255.255
!
no ip address
shutdown
half-duplex
!
interface Serial0/1
ip address 10.10.10.5 255.255.255.252
tag-switching ip
clockrate 64000
!

interface Serial1/2
ip address 172.16.2.1 255.255.255.252
!
interface Serial1/4
ip address 172.16.4.1 255.255.255.252
!
!
router eigrp 1
auto-summary
!
network 172.16.0.0
no auto-summary
exit-address-family
!
router ospf 1
router-id 10.10.10.102
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no auto-summary
!
no auto-summary
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
ip http server
ip classless
!


!
call rsvp-sync
!
!
end
Router CE1-A
CE1-A#show run

!
version 12.2
service timestamps debug uptime
service timestamps log uptime
!
hostname CE1-A
!
!
ip subnet-zero
!
!
!
!
ip address 172.16.10.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
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
!
!
ip subnet-zero
!
ip address 172.16.20.1 255.255.255.0
no keepalive
half-duplex
!
interface Serial0/0
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

!
version 12.2
service timestamps debug uptime
service timestamps log uptime
!
hostname CE3-A
!
!
ip subnet-zero
!
!
no ip domain lookup

!
!
ip address 172.16.30.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
ip address 172.16.3.2 255.255.255.252
no ip mroute-cache
no fair-queue
!
interface Serial0/1
bandwidth 1000
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
!
!
!
call rsvp-sync
!
end
Router CE4-A
CE4-A#show running-config

!
version 12.2
!
hostname CE4-A
!


!
ip subnet-zero
!
!
!
!
ip address 172.16.40.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
ip address 172.16.4.2 255.255.255.252
clockrate 64000
no fair-queue
!
interface Serial0/1
bandwidth 1000
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
!
!
!
call rsvp-sync
!
end
Kiểm tra
(1) Kiểm tra đường đi
CE1-A#traceroute 172.16.20.1
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 *
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 *
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
1 172.16.5.2 16 msec * 13 msec

(2) Kiểm tra các thuộc tính BGP extended community
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
0x8802:32769:20000000 0x8803:32769:1500
Local
172.16.3.2 from 0.0.0.0 (10.10.10.101)
sourced, best
Extended Community: SoO:1:10 RT:1:100 0x8800:32768:0
0x8801:101:2073600 0x8802:32772:20000000 0x8803:32769:1500
10.10.10.102
Local

10.10.10.102 (metric 129) from 10.10.10.102 (10.10.10.102)

0x8801:101:537600 0x8802:61697:20000000 0x8803:61697:1500
Local
172.16.3.2 from 0.0.0.0 (10.10.10.101)
sourced, best
0x8801:101:1049600 0x8802:61698:20000000 0x8803:61697:1500
10.10.10.101
Local
10.10.10.101 (metric 129) from 10.10.10.101 (10.10.10.101)
0x8802:32769:20000000 0x8803:32769:1500
Local
172.16.4.2 from 0.0.0.0 (10.10.10.102)
sourced, best
0x8801:101:2073600 0x8802:32772:20000000 0x8803:32769:1500

10.10.10.101
Local
10.10.10.101 (metric 129) from 10.10.10.101 (10.10.10.101)
0x8801:101:537600 0x8802:32769:20000000 0x8803:32769:1500
Local
172.16.4.2 from 0.0.0.0 (10.10.10.102)
sourced, best
0x8801:101:1049600 0x8802:32770:20000000 0x8803:32769:1500
(3) Kiểm tra bảng định tuyến
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

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).
đó hơi khác với cấu trúc OSPF truyền thống - một backbone Area 0 và nhiều non-
Khi thực thi OSPF với MPLS VPN, khách hàng có thể có nhiều site trong Area 0. Do
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.

superbackbone có chức năng như một OSPF Area 0. Do đó, không yêu cầu
- Các non-backbne area, Area 1 và Area 2, kết nối trực tiếp vào MPLS VPN
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
209.165.202.128/27 được redistribute tại CE2-A và quảng bá tới PE2-AS1 với

LSA Type 5 có metric-type loại 1 (O E1) cho PE2-AS1. Mạng EIGRP
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
xác định chính xác nguồn gốc của các tuyến.

hình sau, cấu hình domain ID giống nhau trên PE1-AS1 và PE2-AS1, chúng ta có thể
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)# 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-af)#redistribute ospf 101 vrf CustomerA match
internal external 1 external 2
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)# redistribute bgp 1 subnets
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
!
interface Loopback0
ip address 10.10.10.200 255.255.255.255
!
interface Serial0/0


ip address 10.10.10.2 255.255.255.252
tag-switching ip
clockrate 64000
!
interface Serial0/1
ip address 10.10.10.6 255.255.255.252
tag-switching ip
clockrate 64000
!
router ospf 1
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
!
ip vrf CustomerB
rd 1:200
!
ip cef
!
interface Loopback0
ip address 10.10.10.101 255.255.255.255
!
interface Loopback101
description OSPF Router ID for VRF CustomerA
ip address 172.16.101.1 255.255.255.255
!
description OSPF Router ID for VRF CustomerB


ip address 192.168.201.1 255.255.255.255
!
interface Serial0/0
ip address 10.10.10.1 255.255.255.252
tag-switching ip
!
interface Serial1/1
ip address 172.16.1.1 255.255.255.252
clockrate 64000
!
interface Serial1/3
ip address 192.168.1.1 255.255.255.252
!
router ospf 101 vrf CustomerA
router-id 172.16.101.1
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
network 192.168.0.0 0.0.255.255 area 1
!
router ospf 1
router-id 10.10.10.101
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no auto-summary
!
no auto-summary
exit-address-family
!

redistribute ospf 201 match internal external 1 external 2

no auto-summary
no synchronization
exit-address-family
!
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
!
ip vrf CustomerB
rd 1:200
!
ip cef
!
interface Loopback0
ip address 10.10.10.102 255.255.255.255
!
description OSPF Router ID for VRF CustomerA
ip address 172.16.102.1 255.255.255.255
!
description OSPF Router ID for VRF CustomerB
ip address 192.168.202.1 255.255.255.255
!
interface Serial0/1


ip address 10.10.10.5 255.255.255.252
tag-switching ip
!
interface Serial1/0
ip address 172.16.2.1 255.255.255.252
clockrate 64000
!
interface Serial1/2
ip address 192.168.2.1 255.255.255.252
clockrate 64000
!
router-id 172.16.102.1
network 172.16.0.0 0.0.255.255 area 0
!
router ospf 202 vrf CustomerB
router-id 192.168.202.1
network 192.168.0.0 0.0.255.255 area 2
!
router ospf 1
router-id 10.10.10.102
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no auto-summary
!
no auto-summary
exit-address-family
!
no auto-summary
no synchronization

exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
ip http server
ip classless
!
end
Router CE1-A
!
hostname CE1-A
!
ip subnet-zero
!
ip address 172.16.10.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
ip address 172.16.1.2 255.255.255.252
no fair-queue
!
router ospf 101
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
!
ip address 172.16.20.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
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
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
network 209.165.201.0
no auto-summary
!
ip classless
!
end
Router CE1-B
!
hostname CE1-B
!
ip subnet-zero
!
interface FastEthernet0/0
ip address 192.168.10.1 255.255.255.0
duplex auto
speed auto
no keepalive
!
interface Serial0/0

ip address 192.168.1.2 255.255.255.252

clockrate 64000
no fair-queue
!
router ospf 201
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
!
description VPN-B site 2 network
ip address 192.168.20.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
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
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
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
O IA 172.16.20.0/24 [110/791] via 172.16.2.2, 00:44:34, Serial1/0
O E1 209.165.201.0 [110/801] via 172.16.2.2, 00:44:34, Serial1/0
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
10.10.10.101
Local
172.16.2.2 from 0.0.0.0 (10.10.10.102)
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
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

O E1 209.165.201.0 [110/865] via 172.16.1.1, 00:41:36, Serial0/0

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
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
O E2 192.168.202.1 [110/1] via 192.168.1.1, 00:12:06, Serial0/0
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
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
theo bởi BGP-based superbackbone. Hai router PE sẽ là endpoint của sham-link.
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
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
(2) Redistribute endpoint vào MP-BGP


(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
!
interface Loopback0
ip address 10.10.10.200 255.255.255.255
!
interface Serial0/0
ip address 10.10.10.2 255.255.255.252
tag-switching ip
clockrate 64000
!
interface Serial0/1
ip address 10.10.10.6 255.255.255.252
tag-switching ip
clockrate 64000
!
router ospf 1
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
!
ip cef
!
interface Loopback0
ip address 10.10.10.101 255.255.255.255
!
description Sham-link Endpoint on PE1-AS1
ip address 172.16.101.1 255.255.255.255
!
interface Serial0/0
ip address 10.10.10.1 255.255.255.252
tag-switching ip
!
interface Serial1/1
ip address 172.16.1.1 255.255.255.252
clockrate 64000
!
interface Serial1/3
ip address 172.16.3.1 255.255.255.252
!
router-id 172.16.101.1
area 0 sham-link 172.16.101.1 172.16.102.1
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
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization


no auto-summary
!
no auto-summary
exit-address-family
!
redistribute connected
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
!
ip cef
!
interface Loopback0
ip address 10.10.10.102 255.255.255.255
!
description Sham-link Endpoint on PE2-AS1
ip address 172.16.102.1 255.255.255.255
!
interface Serial0/1
ip address 10.10.10.5 255.255.255.252
tag-switching ip
!
interface Serial1/0
ip address 172.16.2.1 255.255.255.252

clockrate 64000
!
interface Serial1/2
ip address 172.16.4.1 255.255.255.252
clockrate 64000
!
router-id 172.16.102.1
area 0 sham-link 172.16.102.1 172.16.101.1
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
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no auto-summary
!
no auto-summary
exit-address-family
!
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
ip classless
!
end
Router CE1-A
!
hostname CE1-A
!

!
ip address 172.16.10.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
ip address 172.16.1.2 255.255.255.252
no fair-queue
!
router ospf 101
network 172.16.0.0 0.0.255.255 area 0
!
ip http server
ip classless
!
end
Router CE2-A
!
hostname CE2-A
!
description VPN-A CustomerA Site 2 network
ip address 172.16.20.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
ip address 172.16.2.2 255.255.255.252
!
router ospf 101
network 172.16.0.0 0.0.255.255 area 0
!
ip classless
!
end
Router CE3-A
!
hostname CE3-A
!
interface FastEthernet0/0
ip address 172.16.30.1 255.255.255.0

duplex auto
speed auto
no keepalive
!
interface Serial0/0
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
network 172.16.0.0 0.0.255.255 area 0
!
ip classless
!
end
Router CE4-A
!
hostname CE4-A
!
ip address 172.16.40.1 255.255.255.0
half-duplex
no keepalive
!
interface Serial0/0
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
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

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
O 172.16.2.0/30 [110/782] via 10.10.10.102, 00:33:46
B 172.16.102.1/32 [200/0] via 10.10.10.102, 00:34:17
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
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

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
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
1 172.16.5.2 16 msec 12 msec *

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

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

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
Protocol). Kỹ thuật lưu lượng được phép trên toàn bộ router. Một giao diện loopback
liên kết (OSPF hoặc IS-IS) cũng như giao thức cổng nội IGP (Interior Gateway
Cấu hình đường hầm TE cơ bản.

(mặt nạ 255.255.255.255) sử dụng như MPLS Traffic Engineering router ID (RID).
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ả
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ì
interface Tunnel0
đối với các loại đường hầm khác.

ip unnumbered 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ỉ
loopback0
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

destination 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
tunnel
destination-ip
muốn tạo đường hầm tới. Địa chỉ IP đích là giao diện
Loopback0.
tunnel mpls traffic-eng Cho Cisco IOS biết cách phát sinh đường đi từ đầu đến cuối
paht-option 10 đường hầm.
dynamic
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
flow) tối đa được ngầm định là bằng tham số total-reservable-bandwidth, nhưng

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-
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à
thông tin thay đổi. Có ba nguyên tắc của ngưỡng làm tràn (flooding threshold):
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
(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 Sự thay đổi Băng thông Băng thông Làm Ngưỡng, chiều?
điểm băng thông còn lại (%) được chấp nhận tràn ?
(%) (%)
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.
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
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
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
đườ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.
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,
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 ngầm định (có thể được thay đổi bằng lệnh auto-cost reference-bandwidth)
tham chiếu/ băng thông kết nối (reference-bandwidth/link bandwidth). Băng thông
là 10 8, 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 Xác định một tùy chọn đường đi (path-option) cho đường hầm,
traffic-eng path- tham biến là một giá trị từ 1 đến 1000.
option
preference
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 Khi các đường tường minh được tạo ra, được định danh hoặc chỉ
identifier | name định. Tùy chọn này chỉ định tùy chọn đường đi nào cần quan tâm.
name
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.
Trong MPLS TE, RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-); không
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.
cho các mục đích khác (như VoIP hay DLSW+reservations), RSVP có thể được dù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
để 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.
LSP_TUNNEL_IPv6. Các chỉ số được gán cho C-Types này là 1, 2, 7, and 8.

Ví dụ: lớp SESSION có 4 loại C-Types: IPv4, IPv6, LSP_TUNNEL_IPv4, và
và With Frame Relay Label Range. Các số được gán là 1, 2, và 3. Nếu chỉ có C-Type
LABEL_REQUEST có 3 C-Types: Without Label Range, With ATM Label Range,
= 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 Router ID của đuôi đường hầm.
Endpoint Address
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:
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 Chiều dài prefix của địa chỉ IP
Length
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:


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 0x1 chỉ định sẵn sàng bảo vệ cục bộ (Local Protection
con địa chỉ IP) Available).
0x2 chỉ định bảo vệ cục bộ (Local Protection) đang được
dùng.
Flags (trong đối tượng 0x1 xác định nhãn vừa được ghi là từ không gian nhãn toàn
con - nhã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
được mã hóa giống nhau. Source Instance và Destination Instance để lưu trạng thái
Lớp HELLO có hai C-Types: Hello Request (Type 1) và Hello ACK (Type 2). Cả hai
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:
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ó
chúng được chia xẻ băng thông.

các phần trong five-tuple giống nhau, chỉ khác khác LSP ID, nên khác LSP nhưng
Các bước trong Make-Before-Break:

Bước R1 R2
1 Gửi một sự dành riêng cho Chuyển tiếp sự dành riêng đến R5.
{SA=1.1.1.1, LSP ID=1, EA=5.5.5.5, Đánh dấu đường đi R2 → R5 là 35
TID=8, XTID=0}, yêu cầu 35 Mb dọc Mb được dành riêng cho đường hầm
đường đi R1→ R2 → R5 . Gọi là sự cà còn lại 65 Mb .
dành riêng Res1.

2 Gửi một yêu cầu dành riêng cho Kiểm tra sự dành riêng và thấy rằng
{SA=1.1.1.1, LSP ID=2, EA=5.5.5.5, sự dành riêng này giống với sự dành
TID=8, XTID=0} dọc đường đi riêng đã có ngoại trừ LSP ID. Cho
R1→R3→R4→R2→R5, yêu cầu phép sự dành riêng mới đụng độ với
băng thông 80 Mb. Gọi là Res2. 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
80 Mbps và 20 Mbps chưa đuợc sử

dánh dấu băng thông dành riêng là
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
đối tượng TIME_VALUES trong thông điệp Path và Resv. Mỗi bộ định tuyến cũ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
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:
Địa
Thông điệp
chỉ Cảnh báo
đích
Chức năng Hướng
router
Path Gửi tín hiệu yêu cầu tài Xuôi dòng Đuôi (tail) Có
nguyên lên mạng.
Resv Trả lời thông điệp Path thành Ngược dòng Trạm kế Không
công. (next hop)
Gửi về đầu đường hầm khi có
lỗi ở thông điệp Path.
PathErr Ngược dòng Trạm kế Không
Gửi về phía đuôi nếu có một

lỗi trong việc xử lý thông điệp
ResvErr Xuôi dòng Trạm kế Không
Path.
PathTear Gửi về đuôi đường hầm để Xuôi dòng Đuôi Có
hủy một sự dành riêng đang
tồn tại.
ResvTear Gửi về đầu đường hầm để hủy Ngược dòng Trạm kế Không
một sự dành riêng dang tồn
tại.
ResvConf Gửi phúc đáp cho Resv hay Xuôi dòng Đuôi Có
thông điệp.
ResvTear yêu cầu xác nhận
ResvTearConf Gửi hồi đáp cho một Xuôi dòng Trạm kế Không
ResvTear bao gồm một thông
điệp Confirm.
Hello Gửi tới một láng giềng RSVP Ngược dòng Trạm kế Không
trên một kết nối trực tiếp. / Xuôi dò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
mà còn cần sự định vị nhãn.

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
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ức năng Mặc
chọn định
burst Số lượng tối đa các thông điệp RSVP có thể được gửi trong 200
một loạt truyền

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

MPLS - Tieng Viet

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MPLS - Tieng Viet

Uploaded by

Copyright:

Available Formats

VnPro – Cisco Authorized Training Center

CHUYỂN MẠCH NHÃN ĐA

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

Trần Thị Tố Uyên 1

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

Trần Thị Tố Uyên 2

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

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

Trần Thị Tố Uyên 3

Trần Thị Tố Uyên 4

Trần Thị Tố Uyên 5

EXP tương tự như các bit IP ưu tiên (IP Precedence).

Kiểu tế bào (Cell mode):

Trần Thị Tố Uyên 6

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

HEC (Header error check): Kiểm tra lỗi tiêu đề.

Chuyển đổi thông tin

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

Các gói IP Bảng định tuyến IP

Các gói được Cơ sở định tuyến chuyển Các gói IP được

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

Trần Thị Tố Uyên 7

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

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

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

Trần Thị Tố Uyên 8

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

Trần Thị Tố Uyên 9

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

Trần Thị Tố Uyên 10

Sự duy trì nhãn MPLS

Trần Thị Tố Uyên 11

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

Trần Thị Tố Uyên 12

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)

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

Trần Thị Tố Uyên 13

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

Bước 1: Cho phép CEF

Bước 2: Cấu hình giao thức định tuyến IGP

Trần Thị Tố Uyên 14

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 mpls ldp discovery

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

Trần Thị Tố Uyên 15

tib entry: 10.10.10.101/32, rev 4

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

Trần Thị Tố Uyên 16

Current configuration : 912 bytes

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

Trần Thị Tố Uyên 17

10.10.10.0/30 attached Serial0/1

LSR1#show mpls interfaces

LSR1#show mpls ldp discovery

Trần Thị Tố Uyên 18

LSR2#show cdp nei

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

Trần Thị Tố Uyên 19

LSR2#show cef int s0/0